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ABSTRACT 


The threat posed by malicious software and networked adversaries to computers 
has resulted in the development of mechanisms to provide assurance that security 
sensitive information is not being compromised. One such mechanism is called a Trusted 
Path. A Trusted Path provides a protected communications channel that pennits the 
computer to authenticate itself to the user and for the user to authenticate to the system. 

This thesis provides a demonstration implementation of a Trusted Path for 
Security Enhanced Linux (SELinux) and is used to examine trusted paths, their design 
and implementation. Additionally, the effectiveness of a Trusted Path for SELinux is 
analyzed. 

This research is meant to provide a framework that could be used in combination 
with other efforts to enhance the security of SELinux. 
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I. INTRODUCTION 


A. OVERVIEW 

The widespread incorporation of computing systems into the everyday lives of 
average people has led to the realization that computers need to be ‘secure’. There are 
numerous news articles which describe computer security concerns as well as the ‘hack’ 
of the week. Why computers need to be ‘secure’ can be readily described in terms of the 
need to protect infonnation. Governments, businesses and individuals rely on 
information stored in computers to be correct, safe from eavesdropping and to be readily 
accessible. In computer security terms, the user needs assurance that his information 
stores support confidentiality, integrity and availability. 

The need for computer security is not new but the requirement is increasing as 
more infonnation is stored electronically and the number of interconnections between 
computer systems increases. As a small part of the general research in computer security 
subjects, this project will explore the implementation of a trusted path in Security 
Enhanced Linux (SELinux). This version of Linux is part of a National Security Agency 
(NSA) research project pursuing architectures for more secure operating systems. The 
addition of a trusted path to SELinux would increase the user’s protection from password 
sniffing software and is a common security feature in medium and high assurance 
operating systems. 

B. HISTORICAL BACKGROUND 

Following quickly the development of general purpose computing machines, 
concerns about computer security arose. Initially the concerns were focused on non- 
malicious activities that could affect other computer users or that could cause inadvertant 
corruption of the operating system, but it soon became apparent that malicious behavior 
could be a threat. In 1970, a Rand report by Ware [1] described some of the potential 
computer security threats to the Department of Defense. The Ware report also made 
some general recommendations as to approaches to address the issues but it fell short of 
providing a concrete general purpose solution to the problems. 
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A general solution to the computer security problem was proposed in a paper by 
Anderson in 1972 [2]. Anderson’s proposal was to create a reference monitor that would 
oversee all security related activities on the computer. Specifically, the reference monitor 
would ensure that all data accesses were correct in terms of pennissions and actions. The 
reference monitor is generally accepted as an idealized mechanism to provide security in 
a ‘high-assurance’ computer system. Another related concept is the Trusted Computing 
Base (TCB). In the National Infonnation Assurance Glossary [3], the TCB is defined as 
the 

[tjotality of protection mechanisms within a computer system, including 
hardware, firmware, and software, the combination responsible for 
enforcing a security policy. 

The TCB consists of more than an implementation of a reference validation 
mechanism and includes such things as identification and authentication, the security 
administrator interface, audit retrieval and analysis functions [4]. 

A potential security problem with computer systems is that it is possible to write a 
computer program that can impersonate the login process or other security sensitive 
operation. This could allow the capture of a user’s password and ID. This area of 
concern was identified as early as 1975 by Saltzer and Schroeder [5]. The idea of 
ensuring that a user was talking to the ‘Trusted Computing Base’ was required for some 
levels of computer assurance in the ‘Orange’ book [6]. 

DoD 5200.28-STD: The TCB (“Trusted Computing Base”) shall support a 
trusted communication path between itself and user for initial login and 
authentication. Communications via this path shall be initiated 
exclusively by a user. 

This trusted communication path is generally tenned a trusted path and is needed 
to give the user assurance that he is indeed communicating with the trusted computing 
base and not some software spoofing the TCB. Conversely, it also provides assurance 
that the operating system is connected to the user. The trusted path is important when the 
user identifies himself to the computer through the use of some sort of authentication 
process to avoid the malicious capture of the user’s authentication information. 
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C. PURPOSE OF STUDY 

1. Scope and Assumptions 

This thesis will assess the requirements for a Trusted Path in Security Enhanced 
Linux. The publicly available information about the various Trusted Path 
implementations will be reviewed in an attempt to identify significant design 
considerations. After reviewing previous work in this area, a design for a Security 
Enhanced Linux implementation of a Trusted Path will be proposed and implemented. 

2. Research Objectives 

The Infonnation Assurance Research Office of the National Security Agency 
(NSA) has worked with various research organizations to develop Security Enhanced 
Linux [13]. One purpose of NSA’s research is to provide a demonstration project of how 
mandatory access controls (MAC) can be used to confine processes to prevent security 
issues. The project is also working on developing a security implementation architecture 
that is flexible enough to allow for the implementation of various security policies [17]. 

The research presented in this paper is meant to provide a design document for 
Trusted Path implementation using the Security Enhanced Linux as a demonstration 
project. 
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II. OVERVIEW OF SECURITY ENHANCED LINUX 


A. BACKGROUND 

Information assurance is a very active concern of the U.S. government, especially 
in the agencies and departments that deal with highly classified information. It seems 
reasonable that Top Secret infonnation stored on computers should be protected from 
unauthorized disclosure, e.g. protected from computer hacking. The National Security 
Agency (NSA) is concerned with systems that are capable of protecting the agency’s 
sensitive infonnation. As a result, the NSA conducts research in improving computer 
security, and operating system security is an area of particular interest. 

One of the current computer security debates is whether “open source” software is 
more secure than proprietary software. This discussion pertains to the relative security of 
each of the software models. The Linux operating system is the most commonly 
identified open source software in these discussions and is identified as open source 
because the source code is freely available. Most of the development of Linux is 
performed by various volunteers throughout the world. Proponents of open source 
believe that the availability of the source code for review by all users improves security. 
These users provide a potentially large number of reviewers to identify and correct some 
of the potential vulnerabilities. Others believe that the availability of the source code 
allows users to modify it to meet their particular security needs. Another potential 
advantage for open source software is the ability of the multitude of developers to react 
quickly to discovered vulnerabilities by providing software patches. 

At the other end of the spectrum is proprietary or closed source code software, 
such as the Microsoft operating system. Proponents of these types of products believe 
that open source products provide the potential hacker with an advantage in finding 
potentially exploitable vulnerabilities. They also cite the responsiveness of the 
commercial software industry as a key factor in providing the needed security. 
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An argument can also be made that by controlling the software from design 
through implementation to final delivery gives the commercial software company the 
ability to ensure security of the product. While this control of the entire product could 
help ensure the security of the system, in practice, it does not appear to function that way. 
Many commercial products have had additional software functionality, commonly 
referred to as ‘Easter Eggs’, embedded in the product by the implementation team. Some 
Easter eggs have included significant amounts of code such as the flight simulator found 
in an older version of Excel. Additional infonnation about this and other ‘Easter Eggs’ is 
available at the Easter Egg Archive [28]. If the implementers can include an 
unauthorized flight simulator what prevents the addition of more malicious functionality 
by a member of the team? Witten, et al., [21] provides an excellent discussion of some 
aspects of the subject. 

Ultimately, open vs. closed source is not particularly relevant to medium or high 
assurance software as defined by the U.S. Government. Open and closed are really 
economic models that describe how groups generate profit from the software. Assurance 
or computer security could potentially be provided under either model. What provides 
the needed assurance is the rigor of the development methodology. Without a fonnal and 
methodical approach to the design, implementation, testing, configuration management, 
etc., software will continue to have large numbers of bugs, including those that are 
security related, regardless of the economic model of the software. Generically, 
computer systems that have undergone a formal security design process can be termed 
trusted systems because of the assurance provided by the process. 

Trusted computer systems have many characteristics that make them distinct from 
commonly used systems [2]. The lack of mandatory access controls (MAC) was 
identified as functionality absent from most ‘mainstream’ operating systems. As a result, 
NS A developed a MAC architecture that could be used for many current operating 
systems and flexible enough to allow a wide range of security policies to be applied. 
This architecture is known as Flask and Security Enhanced Linux (SELinux) is a research 
prototype of the Flask architecture [12]. 
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Flask separates policy from enforcement as a means of increasing the flexibility 
of the system. NSA had a generic security policy built by NAI labs to support the 
SELinux demonstration project. SELinux provides some support for multilevel security 
but the implementation is incomplete at this time and is not used regularly within the 
SELinux user group. The selection of Linux as a demonstration platform for Flask was 
driven by the open source nature of the ongoing development and the desire to improve 
the security of a widely used platform [12]. 

B. SELINUX SECURITY OVERVIEW 

The remainder of this section will address the specifics of the Flask demonstration 
implementation and its generic security policy. The following is based on the version of 
SELinux for the Linux 2.6 kernel. This kernel adds support for extended security 
attributes and made significant changes to the previous SELinux implementations. 

SELinux can be viewed as having two primary components: a security policy and 
the enforcement mechanism. Policy is contained in the security server and enforcement 
is performed by object managers. 

The security server is responsible for the security policy and for making 
determinations about security access. This server is located in the kernel as a subsystem 
and provides application program interfaces (API) that the object managers can query for 
security detenninations. For example, if a user attempts to access a file, the file system 
object manager will submit the user credentials and the file attributes to the security 
server to determine if the user has the authority to access the file in the manner requested. 
The server is also responsible for security of the security policy. 

The various object managers enforce the policy decisions of the security server. 
Object managers include kernel subsystems such as process management, file system, 
and socket IPC. When a process attempts to access an object for the first time, the object 
manager contacts the security server with the security contexts. The security server 
performs a look up to detennine if a specific access is allowed and returns a decision to 
the calling object manager. The object managers may cache the decision in an access 
vector cache (AVC) in order to speed up recurring accesses. There is a mechanism to 

allow revocation of access permissions if the policy changes while an object is open. 
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This revocation mechanism is described as the most complex aspect of the Flask 
architecture in [10] and requires additional communication between the object managers 
and the security server to allow updating of policy settings even if an object is open. 

C. SELINUX SECURITY CONCEPTS 

1. Type 

Each object, such as directories, files, and sockets, is assigned a type. An access 
matrix is created that contains allowable accesses between types. An access must be 
explicitly defined as allowable per the SELinux implementation of principle of least 
privilege. There are more than 140 different types in the default SELinux installation and 
they are grouped into seven categories: 

• Device 

• Devpts -pseudo terminal devices 

• File 

• Network 

• Network File System 

• Proofs - process context file system 

• Security 

2. Domain 

Each process runs in a domain. The domain controls what the process can access. 
It is very much like the idea of types for objects and is stored in the same data structure as 
the types. There are in excess of 160 domains in a default install of SELinux including 
admin, user, auth-net, fcron, kernel, startx, and more than 150 various program domains. 

3. Identity 

Each user has a SELinux identity in addition to a standard Linux user ID. This 
can be confusing because the identity and ID are typically the same name. Normal 
commands that can change a Linux ID, e.g. su, do not change the SELinux identity. 

Example: 

Root performs an id command 

root@localhost selinux]# id 

uid=0(root) gid=0(root) groups=0(root), 1(bin), 2(daemon), 

3(sys), 4(adm), 6(disk) , 10(wheel) 

context=root:sysadm_r:sysadm_t 


8 




Root su’s to ahilchie 

[root@localhost selinux]# su - ahilchie 


Root performs an id command as ahilchie 

[ahilchie@localhost ahilchie]$ id 

uid=500(ahilchie) gid=500(ahilchie) groups=500(ahilchie) 
context=root:sysadm_r:sysadm_t 

In the example above the uid, gid, and groups are the Linux identity while the 
context is SELinux identity information. 

4. Role 

A role is a collection of domains that some grouping of users can enter. 
Currently, the domains that a particular user can enter are identified in various 
configuration files. 

5. Security Context 

A security context consists of an identity, a role and a domain or type. 

Example contexts: 

identity:role:domain or type 
Init process system_u:system_r:kernel_t 
Root root:sysadm_r:sysadm_t 

User ahilchie: user_r:user_t 

6. Transition 

Transition decisions are made to determine the correct security context for a 
particular operation. As an example, if a user (ahilchie) creates a new file in his home 
directory, it will have a security context of ahilchie:object_r:user_home_t but the same 
file in the /tmp directory would be ahilchie:object_r:user_tmp_t. 

D. SELINUX SECURITY ASSESSMENT 

SELinux is not a high assurance system. It is Linux with additional security 
policies. There has been no attempt to correct any deficiencies in the underlying 
operating system. As noted on the NSA SELinux web page: 
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This work is not intended as a complete security solution for Linux. 
Security-enhanced Linux is not an attempt to correct any flaws that may 
currently exist in Linux. Instead, it is simply an example of how 
mandatory access controls that can confine the actions of any process, 
including a superuser process, can be added into Linux. The focus of this 
work has not been on system assurance or other security features such as 
security auditing, although these elements are also important for a secure 
system. [17] 

Security system subversion remains a very real possibility. It would be possible 
to create a program and add it to a Linux distribution. Properly coded, the added program 
could provide any desirable level of access to the system. As an example of the potential, 
consider Karger and Schell’s suggestion of a compiler trapdoor [20] which was 
elaborated by Ken Thompson in his discussion of UNIX system security [15]. For a 
discussion of the threat of subversion see Anderson, et al [19]. The inclusion of 
programs in the Linux source tree is not tightly controlled nor are the programs 
rigorously examined (in a formal methods manner) prior to being added. 

A more simplistic attack vector would be to use some current exploit against the 
Linux kernel. These exploits are uncovered regularly and, depending on the properties of 
the exploit, might allow a malicious user to subvert the SELinux MAC policy and take 
control of the system. 

Security Enhanced Linux is a fairly complex overlay to the Linux operating 
system and contains in excess of 350 configuration files. The Linux system is also a 
complex system. Complexity is a serious challenge to security for a number of reasons 
[2]. This complexity presents very real challenges to administration of the system. 
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III. COMMON CRITERIA TRUSTED PATH REQUIREMENTS 


Traditionally, trusted computing systems have been predominately used by 
governmental organizations 1 . This chapter will look at the U.S. Government 
requirements for a trusted path in these types of systems. This review of governmental 
standards will provide a framework for the demonstration implementation of the Security 
Enhanced Linux trusted path. There has been considerable effort made by many people 
to identify and codify various aspects of assurance that can be leveraged in this project. 

The U.S. Government and many other nations have adopted the Common Criteria 
as the security standard for computing systems. The Common Criteria identifies a 
Security Functional requirement class, ‘FTP: Trusted Path/channels’ [7]. The Trusted 
Path class identifies several requirements for a trusted path including: 

Trusted path requires that a trusted path between the TSF2 and a user be 
provided for a set of events defined by a PP/ST author. The user and/or the 
TSF may have the ability to initiate the trusted path. 

The TSF shall provide a communication path between itself and local 
users that is logically distinct from other communication paths and 
provides assured identification of its end points and protection of the 
communicated data from modification or disclosure. 

The TSF shall require the use of the trusted path for initial user 
authentication. 

In other words, the trusted path must be an unforgeable communication 
mechanism between the user and the TCB. Once the user initiates the trusted path, he 
can be certain that the TCB has taken control and as long as the user remains in the 
trusted path, then, there is confidence that any software trying to spoof the TCB is 
thwarted. 

1 Evaluated systems have been predominately used by governments; it could be effectively argued that 
commercial enterprises should have a significant interest in these systems as well. For the government, the 
compromise of sensitive information could have dire consequences. The same argument is applicable for 
businesses. The compromise of some types of sensitive business information could even result in the 
complete failure of the business. 

- Target of Evaluation Security Functions - Parts of the system that have to be relied upon for 
enforcing security policies 
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The Common Criteria allows for the TSF to initiate a trusted path. This capability 
on the part of the TSF would either degrade the level of security and/or significantly 
increase the complexity of the TCB. Typically the trusted path is entered into by the 
system reacting to some user action. The TCB reacts to the user input and provides 
assurance that the communications between the user and the TCB are protected. If the 
system is allowed to initiate a trusted path, the user would be unable to determine if the 
communications path is to the TCB or to a spoofing program. This implies that the TCB 
would have the responsibility to prevent any system output that appears to be a trusted 
path. While this may be possible, it would increase the complexity of the TCB’s 
responsibilities with regard to system output and therefore, reduce the system security. 

The National Information Assurance Partnership (NIAP) is an affiliation between 
the NSA and Common Criteria Vendors. NIAP maintains a Public Interpretations 
Database [8] of detenninations made by the Interpretation Board. These are meant to 
provide additional details of the security requirements required under the Common 
Criteria. The NIAP Interpretation 1-0191: Minimum Set Of Actions That Require Trusted 
Path identifies the following required functions: 

Authentication. 

Session establishment where identification is provided. 

Requests to change the subject sensitivity label. 

Requests to display the current subject's complete sensitivity label. 

Requests to assume a security administrative role. 

This list identifies a set of actions which if implemented by the operating system 
must use the trusted path mechanism. The common thread in the listed items is that they 
have some security sensitive function. In the case of authentication, the user is providing 
some sensitive user identifying information (typically a password) that must be protected 
from entities outside of the TCB. Performing security sensitive actions on a system also 
requires that the administrator ensure that he is dealing with the TCB prior to issuing 
security relevant commands. 
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The sensitivity label requirements are for multilevel systems. These are computer 
systems that are used to process information at different levels of sensitivity and where 
there is a requirement to prevent information ‘leakage’ between different sensitivity 
levels. A concrete example of a multilevel secure system would be a single computer 
where both Top Secret and Secret information is processed. It is important to ensure that 
no Top Secret information can be accessed by a non-Top Secret process. If some 
software at the Secret level was able to spoof being a Top Secret process, it is possible 
that information could be compromised. The trusted path provides the authorized user 
with the ability to select the appropriate level for a session. 

Another aspect of the Common Criteria framework are protection profiles. A 
protection profile is essentially a high level, abstract statement of system security 
requirements. An organization, such as a government, could create a protection profile, 
thus stating its security requirements. In this situation a user might be a specific 
government agency with specific requirements for security. This agency would then 
develop a protection profile that identifies all of its security requirements. Vendors 
would then be able to develop products that meet the protection profile requirements. For 
this project, there is no protection profile identified so we assume that the desire is to 
have a medium assurance system and design the trusted path to meet an evaluated 
assurance level 4 (EAL4) requirements. 
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IV. AN ABSTRACT TRUSTED PATH 


The previous chapter defines the basic requirements of a trusted path. The 
primary requirement was that the trusted path must provide an unforgeable 
communication path between the user and the trusted system. This path is invoked by the 
user and must be evoked under certain conditions. 

Open source documentation of trusted path design is limited in availability, 
therefore, this section will attempt to explore the design considerations for an abstract 
trusted path. “Abstract” is used to mean that the trusted path design considerations are 
removed from the actual details of the operating system and the computer hardware. 

A. ASSUMPTIONS 

This abstract trusted path will be confined to analysis of the trusted path as a local 
problem, i.e., the users will be at the system’s local terminal. This paper will not address 
the more complex issue of a network trusted path. This project will also focus on a single 
user system in a single level security environment. In the design, we will attempt to 
allow the basic structure to be extendable to multi-user multilevel environments but these 
features are not part of the project. 

It is assumed that the security policy requires that each user must authenticate to 
the system through the trusted path for each and every computer session. 

A trusted computing base (TCB) is assumed to exist and is not corruptible. The 
evaluation assurance level of the TCB must be commensurate with that of the trusted path 
and vice versa. An implementation of a trusted path might be likened to installing very 
secure external doors in a house. These external doors might be impregnable but the 
security of the house is also dependent upon preventing unauthorized access from 
windows, walls, etc., as well. The addition of a trusted path to Security Enhanced Linux 
will not correct any potential pre-existing vulnerabilities in this operating system. 
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B. THREATS 

Any security relevant design should be based on a ‘threat model’. This means 
that potential threats to correct functioning should be identified in order to develop 
strategies to counter those threats. A human metaphor will be used to develop the 
potential threats. 

Alice (our user) has a secret (her password) that she wants to give Bob (our TCB). 
Crafty Hacker is the enemy and he wants to steal Alice’s secret or, in some cases, keep 
Bob from getting it. Alice knows Bob and so her trusted path is achieved by the physical 
recognition of Bob. How can Crafty accomplish his goals? 

He could lurk around the corner and eavesdrop on the conversation. 

He could pretend to be Bob (perhaps he is a master makeup artist). 

If these two approaches fail, he could then prevent Alice and Bob from meeting in 
a secure manner (standing between them)? 

In the computer security parlance: 

1. Sniffing 

Essentially this is eavesdropping on the conversation. In our trusted path scenario 
this would require modifying some of the software used for the trusted path to allow 
redirection of the data. 

2. Spoofing 

This is impersonating some portion of the trusted path or TCB to allow capture of 
the sensitive data. Spoofing the logon process with a fake logon screen that accepts the 
user logon information, throws an error, and then starts the real logon process would be 
the classic example. A more sophisticated approach would be a man-in-the-middle attack 
where the spoofing software pretends to be the user to the TCB and the TCB to the user. 

3. Denial of Service 

DOS is the preventing of transmission of information. A process could be created 

with the purpose of preventing valid users or the TCB from accessing the trusted path. 
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4. Circumvention of the Trusted Path 

There exists one other threat to our trusted path: circumvention of the trusted path. 
This circumvention is described as system subversion and is defined as ‘. the covert and 
methodical undennining of internal and external controls over a system lifetime to allow 
unauthorized or undetected access to system resources and/or information.’ [18] The 
extent of the subversion threat is discussed in Anderson et al 2004 [19]. The subversion 
problem could be exemplified by a backdoor being installed in the system in order to 
avoid having to use the trusted path. 

The high level system goals will be presented and then the methodology to 
prevent the threats will be developed. 

C. SYSTEM GOALS 

A user needs assurance that he is communicating with the trusted computing base 
prior to perfonning security sensitive operations. Examples of security sensitive 
operations include authentication, changing passwords and performing some 
administrative actions. The special case of authenticating to the trusted computer base 
will always occur at the beginning of a session and precedes other trusted path 
operations. Security sensitive operations will occur after the user is authenticated and 
while in the trusted path. Also, we may want to support authentication as a different role 
during an established session, e.g., su to root in the Unix sense. 

How does the user invoke the trusted path? Any input methodology could 
potentially be made to work. This could be as simple as a keystroke combination or as 
complex as the use of a smart card inserted into a system card reader. Many current 
computer systems use either a keystroke combination, the mouse position or a click on 
the screen. Examples of the keystroke approach are found in the XTS 400 system [23] or 
the Windows 2000 operating system [24]. Trusted Solaris systems use the position of the 
mouse [25]. It would even be reasonable to have a separate button on the computer to 
invoke the trusted path. Generically the method to invoke a trusted path is referred to as 
a secure attention key (SAK). 
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How does the user know that the trusted path is in effect? Once again there is a 
range of potential ways to inform the user that the trusted path is in effect. The only real 
limit on this is the output capability of modern computers. Approaches could include 
some special LED on the computer or computer monitor that would only be on if the 
trusted path was in effect. Trusted Solaris has a special area on the screen that can not be 
affected by non-TCB processes. A simple approach is to guarantee that pressing the 
SAK always invokes the trusted path. This appears to be the approach used by the XTS 
400 and in the Windows NT family. The TCB must be able to protect the SAK 
invocation; in other words, once the SAK is initiated, no process should be able to 
prevent that signal from reaching the TCB. This will prevent some process from 
intercepting the SAK and presenting a spoofed trusted path. 

Once the trusted path is invoked, the input and output from the trusted path must 
be protected from any and all other un-trusted processes. Conceptually this could be 
achieved by approaches such as terminating or suspending any running un-trusted 
process. Another approach would be to create a separate and isolated process for use by 
the trusted path; the major concern in this approach would be to prevent the other 
processes from gaining access to the tenninal. 

D. SUBVERTING THE SYSTEM GOALS 

Sniffing and spoofing threats can be avoided by careful design. Toward that end, 
there are two design facets that need to be addressed. First, that the SAK must always be 
controlled by the TCB and second, the TCB must block any input and output from 
untrusted software while the trusted path is in effect. The combination of these two 
design facets will prevent both sniffing and spooling of the trusted path communication. 

Preventing denial of service (DOS) is more difficult because the problem is larger 
than the trusted path. There is no way for the trusted path to prevent the majority of DOS 
attacks. A type of attack that the trusted path would be unable to prevent is unplugging 
the computer. In terms of the trusted path, what types of DOS attacks should be 
prevented? Any set of non-TCB processes should not be able to prevent a user from 
invoking the trusted path. This may be achievable within the TCB and requires that the 
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TCB process keyboard interrupts correctly. If the TCB can guarantee that the SAK 
generates an interrupt, which can be used to start the trusted path, then the problem is 
adequately solved. This does not solve all potential denial of service issues. 

The last threat is the circumvention issue. This project will not attempt to address 
all manner of system subversion. Only a high assurance system, such as those 
constructed to meet EAL 6 and EAL 7 criteria, can provide any confidence that the 
system has not been subverted 

E. DESIGN APPROACHES 

A primary design goal is simplicity. Saltzer and Schroeder identified complexity 
as a major security issue in their seminal work in 1975 [5]. This implementation will 
attempt to minimize complexity unless doing so will reduce security. Most of the high 
level design decisions are made based on this goal. These include: 

• The trusted path shall be activated by a keystroke combination (SAK). 

• Pressing the SAK shall always invoke the trusted path. 

• The software implementation of the trusted path should be as small as 
possible. 

• The trusted path mechanism will be as simple as possible. For example, 
the trusted path will not use a ‘windows style’ graphical display due to the 
large amount of code that would have to be trusted. 

• The other running processes will be isolated from the trusted path to 
prevent them from being able to communicate with the trusted path, 
keyboard or the computer monitor. 

• The authentication mechanism shall only accept input from the trusted 
path. 
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V. DESIGN REQUIREMENTS FOR THE SECURITY 
ENHANCED LINUX TRUSTED PATH 


The Common Criteria defines three functional requirements for a medium 
assurance trusted path. The preceding abstract trusted path discussion identified some 
additional design goals. This chapter will present the specific design requirements that 
were used in this project to design the SELinux trusted path. 

A. COMMON CRITERIA REQUIREMENTS 

The Common Criteria Security functional requirements document [22] provides a 
template that allows system designers to select from various phrases to build a Common 
Criteria protection profile. As an example, the following is the first Common Criteria 
requirement for a trusted path: 

FTPTRP.1.1 The TSF shall provide a communication path between itself 
and [selectiomremote, local] users that is logically distinct from other 
communication paths and provides assured identification of its end points 
and protection of the communicated data from modification or disclosure. 

Based on the requirements for this demonstration implementation the ‘local’ 
phrase is selected to generate the following statement. Similarly the two other Common 
Criteria trusted path requirements are chosen to create our protection profile statements: 

1 FTP TRP.1.1 

The TSF shall provide a communication path between itself and local users that is 
logically distinct from other communication paths and provides assured identification of 
its end points and protection of the communicated data from modification or disclosure. 

2 FTP TRP.1.2 

For FTP 1.2 the selection was: The TSF shall permit local users to initiate 
communication via the trusted path. 

3 FTP TRP.1.3 

For FTP 1.3 the selection was: The TSF shall require the use of the trusted path 
for initial user authentication. 
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4. Function Requirement Discussion 

FTPTRP. 1.1 really defines a trusted path. The requirement states that the trusted 
path must provide an unforgeable communications link between the user and the trusted 
portion of the operating system. The trusted path must also ensure that, once established, 
any information passed between the user and the TSF must be protected from 
modification and disclosure. 

FTP TRP. 1.2 requires that a user must be able to invoke the trusted path. 

FTP TRP.1.3 states that initial user authentication shall be conducted using the 
trusted path. 

B. NON-FUNCTIONAL REQUIREMENTS 

In addition to the functional requirements there are guiding design principles that 
are important to designing security features. Primarily these principles include 
simplicity, modularity and appropriate layering of the design. 

Simplicity is a very important design consideration which enhances the 
understandability of the code. Increasing complexity increases the probability that 
serious design flaws will exist and decreases the chance that these flaws will be 
discovered during design review. Additionally, increased complexity leads to an increase 
in the likelihood of implementation mistakes. 

Modularity and layering are related to simplicity in terms of design. Designing 
the modules and layers to group similar or related behavior enhance the understandability 
of the design. Placing functionality at the appropriate layer provides the same benefit. 

C. REFINING THE FUNCTIONAL REQUIREMENTS 

The SELinux trusted path has three functional requirements plus several non¬ 
functional requirements. Based on the proposed design, this section defines how this 
implementation meets the common criteria functional requirements for a trusted path 
using functional supporting requirements (FSR). These supporting requirements are 
simply the elements that this design needs to be able to meet the common criteria 
requirements. 
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1. Functional Sub-Requirements Supporting FTP TRP.1.1 

FSR 1 - The TSF provides a trusted path menu to allow the user to select the 
appropriate action to be performed. 

FSR 2 - The TSF suspends all non-trusted path user processes associated with the 
user upon entering the trusted path. 

FSR 3 - The communication path between the keyboard or computer monitor and 
the TSF shall be under control of the TSF while the trusted path is active. 

2. Functional Sub-Requirements Supporting FTP TRP.1.2 

FSR 4 - The TSF is always notified of the secure attention key (SAK) signal. 

3. Functional Sub-Requirements Supporting FTP TRP.1.3 

FSR 5 - User authentication is controlled via the trusted path. 

FSR 6 - Pressing the SAK when there is no authenticated user results in the TSF 
initiating an authentication sequence. 

FSR 7 - Failed authentication results in returning to the initial pre-authentication 

state. 

FSR 8 - Successful authentication results in the display of the trusted path menu. 

4. Additional Functional Sub-Requirements 

The following two sub-requirements are necessary to provide appropriate 
functionality to the SELinux trusted path. 

FSR 9 - Selecting run from the trusted path menu restores any previously 
suspended user processes or causes a new shell process to be spawned. 

FSR 10 - Selecting exit from the trusted path menu tenninates any user processes 
and returns the computer to the pre-authentication state. 

These 10 functional supporting requirements are sufficient to meet the Common 
Criteria functional requirements, and support some additional desirable functionality as 
well. 


23 



THIS PAGE INTENTIONALLY LEFT BLANK 


24 



VI. HIGH LEVEL DESIGN FOR THE SECURITY ENHANCED 

LINUX TRUSTED PATH 


Previous chapters discussed functional requirements for the implementation of a 
trusted path. This chapter will begin with a discussion of some of the key requirements 
for the trusted path design. These requirements will result in architectural requirements 
for the design. The trusted path as a state machine will also be introduced. The final 
section of this chapter presents a set trusted path interfaces to be implemented in order to 
meet the functional requirements. 

A. DESIGN REQUIREMENT DISCUSSION 

To prevent some untrusted process from blocking the TCB from receiving the 
SAK the keyboard scancode should be captured at a low level within the system. This 
capture should occur inside of the kernel. By keeping the SAK processing in the kernel 
we can prevent user space processes from affecting the SAK. 

Blocking any input/output by untrusted processes while in the trusted path can be 
accomplished in a number of ways including destroying or suspending any running 
untrusted processes. Another approach is to isolate the tenninal so that only the trusted 
path can access it. This thesis will suspend user processes to prevent potential spoofing 
or sniffing. 

Ensuring that the authentication process only receives input from the TCB can be 
accomplished by modifying the traditional getty and login processes. Both get tv and the 
login processes currently run in user space. 

B. ARCHITECTURAL REQUIREMENTS 

The design requirements call for processing in both the kernel and in user space. 
This drives us toward two separate code modules. One module will be part of the kernel 
and will be responsible for kernel-related trusted path processing. The other module will 
be in user space. The functions performed by each module are listed as follows. 
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1 . 


Trusted Path Kernel Module (TP Kern) 

Catch the SAK 
Suspend user processes 
Restore user processes 
2. Trusted Path User Module (TP User) 

• Maintain trusted path state 

• React to TP_Kem SAK pressed message 

• Control the TTY 

• Display initial press SAK message 

• Display TP menu 

• React to input from TP menu 

• Control user authentication 

• Start a command shell 

• Initialize TTY 

C. TRUSTED PATH STATES 

From the perspective of a trusted path we can view the computer as a state 
machine with several distinct states. 

1. Stopped 

In the stopped state the system is powered down and unavailable for interaction. 
It will transition to the next state as a result of the boot process. In and of itself this state 
is not interesting in the context of the trusted path. 

2. Awaiting SAK from User 

In the no user state there are no user processes running on the machine but all of 
the necessary boot processes have run. The computer is waiting for a user to begin an 
authentication process. This state will be entered after the system boot process is 
complete. This state is also entered when a user selects exit to end his session with the 
computer or when a user incorrectly authenticates. 

3. Authentication 

In the in_auth state, the user is proving his identity to the TCB. There are several 
distinct steps to the authentication but from the perspective of the trusted path it may be 
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viewed as a single state. Successful completion of the authentication process results in 
moving to the trusted path menu. Unsuccessful completion results in returning to the 
no user state. 

4. In the Trusted Path Menu 

In the inTPmenu state the user has been authenticated and the trusted path is 
awaiting user input on his desired action. All user processes are suspended. There are 
two entry points; this state can be reached by successful completion of the authentication 
process or by pressing the SAK during the normal execution state. There are also two 
exit points, the user may exit the trusted path menu to the userrun state or to the nojuser 
state. While in the in TP menu state, the user is authenticated to the system and the 
trusted path menu is displayed. The trusted path has control of the computer monitor and 
keyboard. 

5. Normal Execution 

The user run state is the condition in which users may run applications and 
processes. The user is authenticated to the system and the trusted path is idle. 

Figure 1 presents a pictorial representation of the trusted path states and the 
transitions between the states. 
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Figure 1. Trusted Path States 

D. INTERMODULE COMMUNICATION REQUIREMENTS 

1. TPKern to TPUser 

Notify Trusted Path User Module that the SAK has been pressed 

2. TP User to TP Kern 

Four distinct messages must be sent from the user space trusted path module 
(UTPM) to the kernel trusted path module (KTPM): 

• Register the process ID (PID) of the UTPM with the KTPM. With this 
information the KTPM can ensure that only the UTPM is making calls to 
the KTPM. It also will allow the KTPM to signal the UTPM. 

• Suspend the processes associated with a particular trusted path ID 
(TPID). The TPID is the PID of the first user process in the parentage 
tree of the any given user process. 
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• Restore the processes associated with a TPID. This is used to restore any 
previously running processes on returning to a running state from the 
trusted path menu. 

• Kill the processes associated with a TP ID. This is used to destroy any 
user processes when the user exits the system. 

E. TP KERN MODULE 

TP Kern is the kernel space grouping of functionality for the trusted path. It is 
coded in the trustedpath.c as well as the trustedpath.h files. 

1. Interfaces 

void handle_tp_sak () 

asmlinkage int sys_trustedpath(int type jnsg, int pid) 

The interface was named with a handle prefix because this naming convention is 
commonly used in the Linux kernel development community. 

2. Databases 

An integer variable, labeled tpid for trusted path ID, was created in the kernel 
schedule header file. This variable is used by the fork process to label each process with 
its original parent process ID. In this context, original parent is used to describe the first 
shell process. The init process is the only user space process started by the kernel and 
can be considered the original process in any process tree. The tp_id captures the session 
level after tp_getty and allows the trusted path to detennine which processes are 
associated with a user session. The tp_id is used to suspend or terminate specific session 
processes as needed. Detailed information about these modifications are presented in 
Appendix D, Schedule Header Modification, and Appendix F, Fork Modification. Figure 
2 presents a graphic representation of process hierarchy. The tp id is associated with 
each session and is derived from the PID of the original shell for each session. 
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Figure 2. Session Grouping by tp_id. 

3. TPKERN External Interfaces 

The following functions are implemented inside of the trusted path kernel module. 
a. void handletpsakQ 

Called by the keyboard driver in response to simultaneous pressing of the 
control and break keys. TPKern responds to the SAK by notifying the trusted path user 
space module with a signal. 
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b. asmlinkage int sys_trustedpath(int typemsg, int pid)) 

This trusted path system call is the user space interface that is used by 
TPUser to send infonnation to the TPKern. This function returns a zero on successful 
completion. There are four messages that were identified as being necessary: 

c. REGISTER 

Called by the trusted path user module on initialization to pass the trusted 
path process ID to the TPKem. This information is stored in a kernel variable. This 
variable is used to allow the TP Kern to signal the trusted path process. 

d. SUSPEND 

Called by TP User to suspend all processes with the same tpid as the 
PID that was passed to the function. This is done by suspending each process with a 
tp id that is equal to the tp id of the passed in PID. The processes are suspended by 
removing them from the run queue of the kernel’s scheduling process. 

e. RESTORE 

Called by TP User to restore all processes with the same tp id as the PID. 
This is done by determining the tp id of the PID. Then each process with this tp id is 
restored by moving the process on the run queue of the kernel. 

f. KILL 

Called by TP User in response to the user ending a session. TPkern will 
then enumerate all the processes associated with the PID’s tp id and then issue a 
force_sig(SIGKILL,pid) to each associated PID as defined in signal.c. 

F. TP USER MODULE 

The TP User module is the user space grouping of functions for the trusted path. 
It is coded in the login.c file which is used to create the tp_getty executable file. 

1. Interfaces 

There are no external interfaces in the traditional sense. The only external input is 
notification of a SAK from the kernel. This is handled by use of a signal handler in the 
tp_getty executable. 

2. Databases 

The primary databases to support the trusted path implementation are a state 
variable and session structure. 
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The trusted path state variable is labeled tp_state and there are four valid states 

identified. These are the same states as identified earlier in this section with the 

exception of the stopped state which is not used. The states are: 

NOJJSER 

INAUTH 

IN_TP_MENU 

USER_RUN 

As a user transitions from one state to the next this variable is updated and is used 
by the tp_getty program to determine the appropriate response to user input. 

The session structure maintains information about the user’s open sessions. 

struct session_struct { 
session_tty 
session_pid 
session_fd 

} sessions 

The session structure is used to capture TTY, PID, and the TTY fde descriptor of 
each session. This infonnation is used to suspend, restore and tenninate all the processes 
associated with a particular user session. 

G. SUPPORTING MECHANISMS 

The keyboard driver was modified to capture the simultaneous pressing of the 
control and break keys. This action causes the handle_tp_sak function to be called in the 
kernel. The keyboard driver modification is described in Appendix E. 

The SE Linux initialization process init is modified to start TP User. No standard 
getty is started. This modification occurs in the inittab file. 
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VII. TRUSTED PATH IMPLEMENTATION 


A. INTRODUCTION 

The details of the Security Enhanced Linux trusted path implementation are 
described at a high level in this chapter. Additional implementation details are described 
in appendices as noted. 

B. CONSOLE TERMINOLOGY 

The tenn console is used in the context of computers with different meanings. 
Zimmer [26] discusses the origins and history of the term console. According to Zimmer 
there are at least four meanings of console: 

• An instrument panel connected to a computer, 

• A display/keyboard unit, 

• A display/keyboard unit with additional instrumentation used to monitor 
system status, 

• A display mode for a monitor device. 

Additionally, the tenns TTY and terminal are commonly used to describe a 
confined display and keyboard unit. Multiple terminals connected to a single computer 
used to be the common operating mode. In the early days of computers, these terminals 
were teletype machines which resulted in the abbreviation of TTY for a terminal. 

With the advent of modern desktop computing, the virtual console was developed. 
Here a single computer and the associated display/keyboard unit have the ability to 
emulate multiple terminals. For example, in Linux it is common to have multiple virtual 
consoles that are displayed on a single monitor and which can be toggled between by 
special keystrokes. Each virtual console can have a different user logged in and may 
perform different functions. 

To further confuse the issue, there is the concept of a tenninal window. This is a 
software program that emulates a terminal inside of a graphic user interface such as X 
Windows. 

For the sake of this paper the following definitions of terminal related terms will 
be used. 
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Console will be reserved for the special case where the primary function of a 
keyboard/monitor is the administration and/or security of one or more systems. 

TTY will be used to refer to the logical virtual console. This choice is driven by 
the TTY construct in Linux, for example, the command tty will return the virtual console 
that the command was entered on. 

Terminal will be reserved for a physically separate keyboard/monitor that is 
attached to a computer. In the common desktop computer environment there will only be 
one tenninal per system. 

The phrase terminal window will describe a terminal emulator inside of a 
graphical user interface. An example of a tenninal window is a program like gnome- 
terminal that provides a TTT-like environment as a window inside an X Windows 
session. 

The phrase computer monitor will be used to describe the physical display device, 
e.g., computer CRT or flat panel display unit. The phrase was selected primarily to avoid 
confusion with the phrase reference monitor which is discussed in previous chapters. 

C. INTERCEPTING OF THE SECURE ATTENTION KEY (SAK) 

Securely intercepting the SAK is critical to providing a trusted path. Once the 
SAK is pressed the trusted path must always be invoked. Untrusted software must not be 
able to prevent the trusted path from receiving the SAK notification. In order to achieve 
this in SELinux, the keyboard driver was modified to notify the kernel module of the 
trusted path when the SAK keystrokes are made. 

Linux Magic System Request Key is included in current versions of the Linux 
kernel and is contained in the sysrq.c file. One of the functions that is provided by the 
Magic System Request is a SAK. This implementation of a SAK is very aggressive and 
essentially kills all of the processes on the TTY. This was not suitable for our 
implementation of a trusted path. Also the Magic System Request did not work at all 
within X Windows on the systems used for this research. Some amount of time was spent 
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attempting to detennine the cause of the X Window problem but it was never precisely 
identified. Both the aggressive nature of the Magic System Request SAK and the X 
Windows issue drove the development of a new SAK 

The keyboard generates scan codes that indicate what keys have been pressed or 
released. This infonnation is passed through various hardware specific drivers to the 
general keyboard driver. All scan codes eventually arrive at the keyboard driver, so this 
is a logical point at which to insert the SAK detection functionality. Changing or 
modifying any of the software drivers between the physical keyboard and the keyboard 
driver requires recompiling and re-installing the kernel which in turn requires root 
administrative privileges. Assurance that the SAK cannot be intercepted by malicious 
code is provided because the kernel would require modification to pennit this. 

The source code of the function which contains the SAK interception code is 
provided in Appendix E. 

D. KERNEL MODULE OF THE TRUSTED PATH 

The trusted path kernel module is primarily a helper set of functionality for the 
user space trusted path program. This module is a communication channel between the 
kernel and the trusted path user space program. In addition, it performs some process 
management. 

There are two primary communication systems that are used by this module. For 
communication from the kernel, signals are used to notify the user space program that a 
SAK has arrived. Signals are a primitive form of interprocess communication (IPC) and 
are somewhat limited in their capabilities. More sophisticated methods of IPC were not 
employed primarily due to the inherent complexity of these methods. This is ultimately 
becomes a design choice between simplicity and functionality. For this implementation, 
the simplicity of signals was more important than additional functionality offered by 
modem IPC methods. The other communication method used in this implementation was 
a system call for sending messages from the trusted path user space program to the 
kernel. The trusted path system call is described below. 
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The kernel module also suspends, restores and terminates processes based on 
information received by the trusted path system call. The system call provides a process 
ID (PID) of the group of processes to be suspended, restored or terminated. Using the 
trusted path ID described below, all of the related processes are identified and the 
appropriate action is performed by the kernel module.The source code of the trusted path 
kernel module is provided in Appendix B. 

E. CREATION OF A TRUSTED PATH PARENT ID 

In this design all user processes are suspended upon entering the trusted path. A 
reliable method to identify all the processes associated with a user is required to 
implement this approach. However, Linux allows changing process parentage 
information in the process table, task_struct. 

To provide the information needed by the trusted path, an additional field was 
added to the process table. This field is an integer process ID labeled as tp_id for trusted 
path ID. This field is populated during the fork process by the kernel with the tp_id of 
parent process unless the grandparent process ID (PID) is 1 in which case the tpid is the 
current process PID. This will result in all processes associated with a user session 
having the same tp id. 

The changes to the original Linux source files required for the trusted path parent 
ID are detailed in Appendix D, Schedule Modification and F, Fork Modification. 

F. ADDITION OF A TRUSTED PATH SYSTEM CALL 

The trusted path design consists of two separate groups of code. One group runs 
in kernel space and the other is a user space construct. To allow the requisite 
communication to occur, there was a need to build a mechanism for the user space trusted 
path process to communicate with the kernel. For the sake of simplicity a trusted path 
system call was implemented. For a discussion on the benefits and disadvantages of 
using system calls see Love [27]. 

As identified in the previous chapter, there are four distinct messages that the user 
space trusted path must be able to send to the kernel: 

• Registration of the user space trusted path, 

• Suspend user processes, 
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• Restore user processes, and 

• Terminate user processes. 

A single system call was designed to allow these four messages be sent to the 
kernel trusted path mechanism. Detailed implementation infonnation is contained in 
Appendix C. 

G. REPLACEMENT OF THE GETTY AND LOGIN PROCESSES 

In the standard SE Linux implementation, the init process will start a small 
number of getty processes. In the SE Linux version used for this research, the getty 
program is named mingetty because it is a minimal version of a getty without some 
features found in other getty programs. Mingetty initializes the various TTYs and waits 
for a user to enter his username. Mingetty then execs to the login program passing the 
username as a variable. Login authenticates the user. Pluggable Authentication Modules 
(PAM) are typically used in modern versions of Linux, including the research version of 
SE Linux, to perform the authentication. 

As discussed in Chapter II, SE Linux uses a security context to limit the behavior 
of processes. In addition to the standard Linux user and group identity, the SE Linux 
security context has an identity, a role and a domain which must be correctly set prior to 
the user having an interactive shell. If PAM is being used as the authentication method 
then an additional SE Linux PAM function is used to set the correct security context. 
After the user is authenticated and appropriate context is set, login forks a bash shell and 
the user gains control of the process. 

The trusted path implementation replaces mingetty and login with a trusted path 
program titled tp_getty. This approach to the TTY initialization and user authentication 
was driven by the state-machine vision of the trusted path described high level design 
chapter. The vision of the trusted path required the ability of the trusted path to control 
the state changes which required modification of the process. Another advantage of this 
process is the reduction in amount of code needed to perform these functions. As an 
example, in order to support the various authentication methods that are possible, the 
standard login program is in excess of 1400 lines. Tp_getty is approximately 500 lines 
shorter. 
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The init process starts the number of tp_getty processes determined by the system 
administrator in the init configuration file, inittab. The tp_getty initializes the ttys and 
waits for the user to press the SAK key combination. Once the SAK is pressed tp_getty 
is notified via a signal sent by the kernel. Then tp_getty uses PAM to authenticate the 
user. Upon successful authentication, the tp_getty displays the trusted path menu for the 
user to select the desired action. For this demonstration project the user may select to 
quit a session, start a new shell or to restore a shell. The behavior of quitting or restoring 
a session is dependent on the number of open shells. If there is only one open shell then 
quitting will log the user out of the system otherwise he will be queried as to which shell 
should be closed. Restoration of a shell displays similar behavior. The total number of 
pennissible open shells is limited to an arbitrary MAX TP SHELLS. 

Starting a new shell forks a new process, the SE Linux context is set for the new 
process, and a new tty is generated. The SE Linux context is set on each shell that is 
started from the trusted path menu to allow a user to open multiple shells in different 
contexts. This is accomplished by using the SE Linux PAM set credentials function 
during the fork process. After setting the context, the user is switched to the new tty and 
he assumes control of the process. Pressing the SAK key combination while in the user 
process causes the user’s processes to be suspended and the user returns to the tty 
containing the trusted path menu. 

There were many challenges to the tp_getty implementation. One was the 
complexity of the Linux login code. To support all the various forms of authentication 
such as Kerberos, crypto cards, PAM and shadow files a significant number of #ifdef 
statements are included in the code. This is an efficient means of updating or modifying 
an existing piece of code, but these additions make it more complex and difficult to 
follow. 

The most complex challenge was associated with the SE Linux security policy. 
SE Linux uses various configuration files to generate policy rules that describe the access 
pennissions for subjects and objects. This research used the NSA example SE Linux 
security policy which contained in excess of 250,000 rules. Detennining how to provide 

tp_getty with the correct access permissions was time consuming. 

38 



In this implementation of the trusted path, the new tp_getty file was given the 
context of system_u:object_r:login_exec_t. This security context allows tp_getty to fork 
processes, use PAM modules, reset TTYs and perform other typical login tasks. Also the 
in it domain was modified to allow the in it process to automatically change it’s security 
domain to login_exec_t thus allowing init to start the tp_getty. The appropriate 
configuration files are contained in Appendix H. 

H. PROCESS SUSPENSION AND RESTORATION 

As part of the design, all user processes must be inactive when the user is 
interacting with the trusted path menu. This is to prevent the possibility of a user process 
intercepting any communication between the user and the trusted path. 

In order to allow a process to be placed in a suspended state, the process must be 
removed from the correct run queue which is a data structure that the kernel uses to 
manage process scheduling. Two additional suspended queues were created in sched.c to 
store the processes that were removed from the run queues. Additionally, the kernel has 
the ability to temporarily store inactive processes in other queues which required the 
addition of a do_not_activate flag in sched.h. This combination allows the trusted path to 
inactivate the user processes. In general, all user processes are suspended prior to 
allowing access to the trusted path. 

After completion of the user interaction with the trusted path, the user may wish 
to restore a session. This situation is somewhat more complicated than the suspend 
process because the user may have multiple sessions that are suspended. The user could 
have zero, one or more than one open session. 

If the user selects restore from the trusted path menu but does not have an open 
session a brief error statement is displayed and the user returns to the trusted path menu. 
If the user has just one open session then that session is automatically restored. 
Otherwise, there are multiple open sessions and the trusted path queries the user to 
determine which session to open. 

I. CONTROLLING THE TTY 

In this implementation, the trusted path menu is displayed on TTY 1. As a user 
opens new sessions, the session is displayed on next available TTY. In Linux it is 
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possible for a user to switch between TTYs with certain keystrokes. To prevent the user 
from switching between a session TTY and the trusted path menu or vice versa it was 
necessary to block the ability of the user to switch between TTYs by locking the switch 
functionality. The trusted path controls the active TTY. Trusting the trusted path 

The kenel needs to know that the trusted path system calls are indeed coming 
from the trusted path menu. Otherwise other software could impersonate the trusted path 
with the potential of denial of service problems. The approach used in this research is 
simplistic and there is a potential problem. The trusted path menu registers with the 
kernel prior to the computer becoming available for user input. The kernel then sets a 
flag to indicate that the trusted path is registered and to prohibit other processes from 
registering as the trusted path. Once this flag is set it is not possible to reset the trusted 
path registration. 

The kernel uses this registration to validate that each system call is coming from 
the trusted path by comparing the PID of the calling process against the previously 
registered PID of the trusted path. 

The flaw in this approach is that if the trusted path menu exits due to some error 
the init process will restart the trusted path menu program but it will not be able to 
register or signal the kernel. The only remedy in this situation is to reboot the computer 
system. This is not a robust solution to the problem and requires additional research. 
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VIII. TRUSTED PATH TEST PROCEDURES 


A. INTRODUCTION 

These test procedures are designed to demonstrate that the trusted path is correctly 
designed and implemented. The testing will demonstrate the correct implementation of 
the functional supporting requirements as defined earlier. This chapter describes the test 
methodology for each of the 10 functional sub-requirements (FSR). An action may test 
more than one FSR, but, for the sake of completeness, the action will be listed under each 
FSR that is appropriate. 

B. FSR 1 

1. FSR 1 Purpose 

The TSF will provide a trusted path menu to allow the user to select the 
appropriate action to be perfonned. 

2. FSR 1 Testing Rationale 

The trusted path menu should always be displayed in three cases. The menu 
should display after a user has successfully authenticated. It should display when the 
SAK is pressed in trusted path state user_run. It should also display if an incorrect 
selection is made from the trusted path menu. The menu should not display at any other 
time. 

3. FSR 1 Test 1 

Correctly authenticate to the system in trusted path state injiuth. The trusted path 
menu should display. 

4. FSR 1 Test 2 

Incorrectly authenticate to the system in trusted path state in auth. The trusted 
path menu should not display. 

5. FSR 1 Test 3 

Press the SAK while in the trusted path state user run. The trusted path menu 
should display. 

6. FSR 1 Test 4 

Press various key combinations that are not the SAK while in the trusted path 

state user run. The trusted path menu should not display. 
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7. FSR 1 Test 5 

Press various key combinations that are not the SAK while in the trusted path 
state no user. The trusted path menu should not display. 

8. FSR 1 Test 6 

Press the SAK while in the trusted path state no user. The trusted path menu 
should not display. 

9. FSR 1 Test 7 

Press various key combinations that are not the SAK while in the trusted path 
state in TP menu. The trusted path menu should display. 

10. FSR 1 Test 8 

Press the SAK while in the trusted path state in TP menu. The trusted path menu 
should display. 

11. FSR 1 Test 10 

Press any single key that is not a trusted path menu selection while in the trusted 
path state in TP menu. The trusted path menu should display. 

B. FSR 2 

1. FSR 2 Purpose 

The TSF will suspend all non-trusted path user processes associated with the user 
upon entering the trusted path. 

2. FSR 2 Testing Rationale 

In order to assure that no other process can imitate the trusted path or intercept 
user-TSF communications, all processes associated with the user should be suspended. 
This suspension must be complete prior to initiating the trusted path menu. Testing of 
process states will require additional code to log process status and the time the status 
changes to determine that all of the necessary processes are suspended prior to initiating 
the trusted path menu. The test code will execute immediately prior to starting the trusted 
path menu. The trusted path process is considered to be a system process. 

3. FSR 2 Test 1 

Enter the trusted path menu by successfully authenticating in trusted path state 
in_auth. The logs should indicate that only system processes are running prior to display 
of the menu. 
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4. FSR 2 Test 2 

Enter the trusted path menu by pressing the SAK in trusted path state user run. 
The logs should indicate that only system processes are running prior to display of the 
menu. 

5. FSR 2 Test 3 

Enter the trusted path menu by selecting any incorrect selection from the trusted 
path menu in trusted path state in TP menu. The logs should indicate that only system 
processes are running prior to display of the menu. 

C. FSR 3 

1. FSR 3 Purpose 

The communication path between the keyboard or computer monitor and the TSF 
shall be under control of TSF while the trusted path while it is active. 

2. FSR 3 Testing Rationale 

This functional sub-requirement does not readily support automated testing. 

3. FSR 3 Test 

Design and code review will be performed by the Thesis advisors. This review 
should not reveal any potential communication path vulnerabilities. 

D. FSR 4 

1. FSR 4 Purpose 

The TSF will always be notified of the secure attention key (SAK) signal. 

2. FSR 4 Testing Rationale 

The TSF must always receive the SAK signal. Some of the following tests will 
also be conducted while evaluating different FSRs and are repeated here for the sake of 
completeness or because the desired result may be viewed from a different perspective. 

3. FSR 4 Test 

Press the SAK while in the trusted path state user_run. The trusted path menu 
should display. 

4. FSR 4 Test 2 

Press various key combinations that are not the SAK while in the trusted path 
state user run. The trusted path should not be invoked. 
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5. FSR 4 Test 3 

Press the SAK while in the trusted path state no user. The trusted path 
authentication process should begin. 

6. FSR 4 Test 4 

Press various key combinations that are not the SAK while in the trusted path 
state no user. The trusted path should not be invoked. 

7. FSR 4 Test 5 

Press the SAK while in the trusted path state injmth. The trusted path login 
process should restart. 

8. FSR 4 Test 6 

Press various key combinations that are not the SAK while in the trusted path 
state injiuth. The trusted path should not be invoked and depending on the keys pressed 
the authentication should fail. 

9. FSR 4 Test 7 

Press the SAK while in the trusted path state in TP menu. The trusted path menu 
should continue to be displayed. 

10. FSR 4 Test 8 

Press various key combinations that are not the SAK while in the trusted path 
state inTPmenu. The trusted path menu should continue to be displayed. 

E. FSR 5 

1. FSR 5 Purpose 

User authentication will be controlled via the trusted path. 

2. FSR 5 Testing Rationale 

This functional sub-requirement does not readily support automated testing. 

3. FSR 5 Test 1 

Design and code review will be performed by the Thesis advisors. This review 
should indicate that the only entry point to the authentication mechanism is through the 
trusted path. 
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F. FSR 6 

1. FSR 6 Purpose 

Pressing the SAK when there is no authenticated user will result in the TSF 
initiating an authentication sequence. 

2. FSR 6 Testing Rationale 

These are the same tests as FSR 4 test 3 and FSR 4 test 4. 

3. FSR 6 Test 1 

Press the SAK while in the trusted path state no user. The trusted path 
authentication process should begin. 

4. FSR 6 Test 2 

Press various key combinations that are not the SAK while in the trusted path 
state no_user. The trusted path should not be invoked. 

G. FSR 7 

1. FSR 7 Purpose 

Failed authentication will result in returning to the initial no_user state. 

2. FSR 7 Testing Rationale 

Failed authentication will cause the computer to return to the no user state and 
will require the user to begin the process over. 

3. FSR 7 Test 1 

Incorrectly authenticate to the system in trusted path state in auth. The message 
to press the SAK to begin authentication should be displayed. 

4. FSR 7 Test 2 

Correctly authenticate to the system in trusted path state injrnth. The trusted path 
menu should display. 

H. FSR 8 

1. FSR 8 Purpose 

Successful authentication will result in the trusted path menu being displayed. 

2. FSR 8 Testing Rationale 

These are the same tests as in FSR 7. 
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3. FSR 8 Test 1 

Incorrectly authenticate to the system in trusted path state in_auth. The message 
to press the SAK to begin authentication should be displayed. 

4. FSR 8 Test 2 

Correctly authenticate to the system in trusted path state in_auth. The trusted path 
menu should display. 

I. FSR 9 

1. FSR 9 Purpose 

Selecting run from the trusted path menu will restore any previously suspended 
user processes or cause a new shell process to be spawned. 

2. FSR 9 Testing Rationale 

The trusted path must restore any previously suspended processes upon return to 
the trusted path user_run state. 

3. FSR 9 Test 1 

While in the trusted path user_run state initiate some number of processes. 
Perform a process listing and save the output to a file. Press the SAK and when in the 
trusted path menu select run to return to the user_run state. Again perform the process 
listing and save the output to a different file. Compare the two files and the only 
difference should be the process listing command which might have a different process 
ID. 

J. FSR 10 

1. FSR 10 Purpose 

Selecting exit from the trusted path menu will terminate any user processes and 
cause the state to change to no user. The TTY will display the pre-authentication 
message requesting potential users to press the SAK. 

2. FSR 10 Testing Rationale 

This will require additional code to generate test results after the user has logged 
out. This code will log running processes after completing the user logout. 
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3. FSR 10 Test 1 

From the trusted path menu select exit then log back into the system and proceed 
to the trusted path user_run state. Review the logs to ensure that all user processes were 
stopped when the no user state was reached. 
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IX. CONCLUSIONS 


A. ANALYSIS AND DISCUSSION 

1. The Increasing Complexity of Software 

As discussed previously in this paper, the complexity of software increases the 
likelihood of security relevant issues in the design and implementation. Complexity also 
decreases the chance that an individual will be able to discover a particular flaw. With 
enough complexity it may not be possible to determine whether a specific piece of code 
has a security issue in the larger context of the code it interacts with. 

Most software in common usage today is being developed in an incremental 
fashion. An example of this is the Microsoft Windows XP operating system. The core 
operating system is modified from Windows 2000 which was modified from Windows 
NT 4.0. This approach to development is efficient and follows the tenant of code reuse 
that is promoted by the software development community but typically results in much 
more complex code. This occurs because additional functionality is inserted into the 
previous code. This additional code adds features but can significantly increase the 
complexity of a group of code and in fact can make it much more difficult to understand 
what are the direct results and side-effects of any given code. 

It can be argued that this evolutionary process is the only economical approach to 
develop large software packages. While this is reasonable, little fonnal thought is given 
to the security implications. As the code becomes more complex, the likelihood of 
significant security problems increases. There is a real economic impact of security 
issues both in the traditional computer security sense and the more mundane sense of 
having to pay system administrators to constantly patch and maintain systems. 

Linux is a very complex set of software packages. Most of the core kernel 
functions have been incrementally modified by many authors to offer an increasing 
number of functions. As an example of this, the scheduling code of the 2.6 kernel is 
2,916 lines in contrast to the 849 lines that were in the 1.0.9 kernel. Any particular thread 
of execution through the scheduler is understandable but the cumulative effects of all the 
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code makes it difficult to understand the scheduler behavior in a meaningful and holistic 
sense. This is just one example but the remainder of the kernel contains similar 
complexity issues. Adding applications software on top of the operating system explodes 
the difficulty of understanding the security relevant software interactions. 

Security Enhanced Linux (SELinux) is a security overlay on the traditional Linux. 
Security-relevant enforcement mechanisms have been added with one goal being 
flexibility. The flexibility of the security mechanism significantly increases the 
complexity of the software. This complexity is in addition to the complexity of the 
underlying operating system. There is a likelihood approaching certainty that significant 
security problems exist in this system, though this is not different from other common 
operating systems. 

The Common Criteria [29] mandates the reduction of complexity as a key factor 
in developing assurance: 

Design complexity minimisation contributes to the assurance that the code 
is understood — the less complex the code in the TSF, the greater the 
likelihood that the design of the TSF is comprehensible. Design 
complexity minimisation is a key characteristic of a reference validation 
mechanism. 

The primary purpose of minimizing the complexity of a system is to allow 
understanding of how the computer system enforces security relevant policy. To state 
that a computer is high assurance demands that the security relevant functions of the 
system are understood through the range of potential inputs and the functions will always 
behave correctly in terms of the security policy. This is the fundamental idea behind the 
reference monitor concept proposed by Anderson [2]. Related to this complexity issue is 
the intermingling of security functions with the remainder of the kernel code. With 
security functions scattered about in thousands of lines of other code, it becomes very 
difficult to understand the behavior of these functions. 

2, Security Enhanced Linux 

SELinux is an interesting research project. The addition of mandatory access 
controls may provide some additional security to the system depending on the SELinux 
policy used. 
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The SELinux example policy that is provided by NS A is a very liberal policy that 
seems to be designed to minimize potential problems for the user. By default, SELinux 
will deny an action unless that action is specifically allowed in the policy configuration. 
This is a correct approach to a secure system but in the provided example policy most 
common actions are specifically allowed. In the example policy provided with this 
version of SELinux there were in excess of 250,000 rules that permitted actions. In 
contrast, a typical firewall or VPN implementation may have 100 rules. This implies that 
a great amount of work would be required to modify this rule set correctly for a given 
situation. 

As long as SELinux is viewed as a research project it has value. It is not high 
assurance and would have difficulty in being classified even as medium assurance under 
the Common Criteria. It should not be deployed as a solution in situations that require 
considerable assurance. 

3. Adding Security to Existing Systems 

Most of the effort of this project was in understanding the existing 
implementation of SELinx and the underlying Linux system. Due to the complexity of 
the current implementation and the lack of design documentation it was difficult to 
determine how and where to insert pieces of functionality. It was also impossible to 
determine the potential effects from other parts of the existing code on the new trusted 
path. This results in some doubt as to the security of the trusted path implementation 
specifically in terms of potential issues arising from within the kernel. Most of code that 
was identified as relevant was examined but that only represents a small fraction of the 
code base and issues such as timing problems were not practical to evaluate. At the core 
of the issue is that this implementation depends on a tremendous amount of kernel code. 
The trusted path requires that the kernel behave correctly. This places a great deal of 
trust in unknown code and programmers. 

It is axiomatic that adding security to an existing system is much more expensive 
than incorporating security from the beginning. This demonstration project demonstrates 
the truth of this statement. The effectiveness of adding security to existing software 
decreases as the complexity increases. At some point the complexity becomes 
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unmanageable and regardless of the efforts to add security very little is accomplished 
because the existing code base is too large and not understandable with respect to the 
added security functionality. This statement is empirically demonstrated by the software 
security patch that results in additional security problems. 

These observations imply that any common operating systems in use today will 
have significant security problems. The code bases of Windows, Linux and Unix are too 
large and complex to prevent potential security issues. The original implementation of 
these products did not have security as a primary design consideration. If the lives of 
DoD personnel depend on the security of data contained in a computer then a high 
assurance system is needed and none of the listed operating systems will meet the 
requirements. 

B. FUTURE WORK 

Ensuring that all trusted path system calls are originating from the trusted path 
menu requires additional research. The current implementation provides rudimentary 
security from processes impersonating the trusted path but may require rebooting of the 
computer if the trusted path menu experiences an error. Additionally, the design of the 
trusted path identifier, tpjd, is very dependent upon the task structure. Further research 
might provide a more robust implementation mechanism for this identifier. 

As currently implemented, the trusted path has been subjected to minimal code 
review and testing. As a single individual with little oversight it is very possible that this 
work contains some errors. An extensive code review and more rigorous testing of the 
implementation must be conducted prior to use of this software in a production system. 
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APPENDIX A. TRUSTED PATH -USER SPACE 


This is the source code for the trusted path user space module. It is derived from 
a number of sources. This represents the majority of the coding effort for this 
demonstration project. 

// Trusted path user space program 

// 

// This program acts as the trusted path 
// for selinux 

// 

// This implementation is part of a 
// masters thesis 

// 

// ahilchie 

// 

// There are major sections which are derived 

// from the standard login.c and mingetty.c used by RedHat 

// 


#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 


<sys/param.h> 

<stdio.h> 

<ctype.h> 

<unistd.h> 

<getopt.h> 

<memory.h> 

<time.h> 

<sys/stat.h> 

<sys/time.h> 

<sys/resource.h> 

<sys/file.h> 

<termios.h> 

<string.h> 

<sys/ioctl.h> 

<sys/wait.h> 

<signal.h> 

<errno.h> 

<grp.h> 

<pwd.h> 

<utmp.h> 

<setjmp.h> 

<stdlib.h> 

<string.h> 

<sys/syslog.h> 
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#include <sys/sysmacros.h> 

#include <netdb.h> 

#include "pathnames.h" 

#include "my_crypt.h" 

#include "login.h" 

#include "xstrncpy.h" 

#include "nls.h" 

// additional includes from mingetty 
#include <fcntl.h> 

#include <stdarg.h> 

#include <syslog.h> 

#include <sys/utsname.h> 

#include <time.h> 

#include "userspace.h" 

// additional includes for vt 
#include <dirent.h> 

#include <sys/vt.h> 

#include <sys/types.h> 

// selinux relevant 
#include <selinux/selinux.h> 

#include <sys/sysmacros.h> 

#include <linux/major.h> 

#include <utmp.h> 

#include <security/pam_appl.h> 

#include <security/pam_misc.h> 

//PAM 

# define PAMMAXLOGINTRIES 3 

# define PAMFAILCHECK if (retcode != PAMSUCCESS) {\ 

fprintf(stderr,"\n%s\n",pam_strerror(pamh, retcode)); \ 
syslog(LOG_ERR,"%s",pam_strerror(pamh, retcode)); \ 
pam_end(pamh, retcode); exit(l); \ 

} 

# define PAM_END { \ 

pam_setcred(pamh, PAM DELETE CRED); \ 
retcode = pam_elose_session(pamh,0); \ 
pam_end(pamh,retcode); \ 

} 

#include <lastlog.h> 

#include "setproctitle.h" 
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#ifdef USETT YGROUP 

# define TTYMODE 0620 
#else 

# define TTY MODE 0600 
#endif 

#ifndef MAXPATHLEN 

# define MAXPATHLEN 1024 
#endif 

#define VTNAME "/dev/tty%d" 

#define TP_VT 1 

// State names for the trusted path 

#dellnc NO_USER 0 // no authenticated user on system 

#define IN_AUTH 1 // user in authentication process 

#deline IN_TP_MENU 2 // user authenticated and tp in control 

#dclinc USER_RUN 3 // user authenticated and tp not in effect 

// trusted path state 

int tp_state = NO_USER; // by default we start w/o a user 
struct passwd *pwd, pwdcopy; 

#delinc MAX_TP_SHELLS 10 // arbitrary max number allow shells 
// A simple session struct 
struct session_struct { 
int session_tty; 
int session_pid; 
int session_fd; //the tty fd 
} sessions[MAX TP SHELLS]; 

int num_open_sessions = 0; // start with no open sessions 
int current session = 0; 

// a couple of functions for dealing with the open session array 
void add_session(int new_tty, int new_pid, int new_fd); 
void delete_session(int session_num); 
void print_array(void); 

char ** env; 
static char * username; 
static char *user_dir; 
char *hostname; 
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static char *progname; 

static char *mg_tty; //mingetty tty 

static pid t pid; 

static int noclear = 0; 

static int nohangup = 0; 

extern char ** environ; 

pam_handle_t *pamh = NULL; 

int retcode; //return code for pam function 

// standard pam conversion function which 
// provides a means to pass text to user from pam 
struct pam_conv conv = { misc_conv, NULL }; 

// error loggin function 

static void error (const char *fmt,...); 

// mingetty standard tty initialization routine 
static void openjfy (void); 

// trusted path signal handling routine 
void tp_signal_catcher(int the_sig); 

// trusted path routine to interact with pam 
// returns 0 on successful completion 
// any nonzero return indicates failure of the 
// the function or pam 
int tp auth(void); 

// displays a message to the user to press the SAK 
void display_SAK_msg(void); 

// The trusted path menu charater catching function 
// valid return values are: 

// s to start a new session 
// q to terminate a session 
// r to restore a session 
char do tp menu(void); 

// printf a bunch of endlines to clear the screen 
void clear_screen(void); 

// printf of the menu choices 
void printtpmenu(void); 
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// error statement if user failed to select 

// a valid menu choice 

void print_tp_menu_error(void); 

// trusted path function to 
// switch to and open a new tty 
// start a new shell 

// returns zero on successful completion 
int tp open shell(void); 

// trusted path function to switch the 
// active tty to int vtno 
// returns a zero on successful completion 
int switch_vt(int vtno); 

// trusted path function to 
// allow the user to pick a session to 
// terminate or restore 
// returns the session number 
int get_session_num(void); 

// trusted path function to 
// terminate a session 

// returns a zero on successfull completion 
int tp_terminate_session(void); 

int main(int argc, char **argv){ 

// set the program name for error logging 
progname = argv[0]; 
if (! progname) 

progname = "trustedpath"; 

/* //remove this to set up the initial 

//vt locking to prevent users from switching 
//between ttys prior to initial login 

int tmp fd; 

tmp_fd = open("/dev/console",O_WRONLY,0); 
ioctl(tmp_fd, VT LOCKSWITCH, 256); 

*/ 


// set up the signal structures so we can 
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// catch kernel sak msg 
struct sigaction tp action; 
tpaction.sahandler = tpsignalcatcher; 
tp_action.sa_flags = 0; 

if (sigaction(SIGUSRl, &tp_action, NULL) == -1) { 
perror("SIGNIT"); 
return 1; 

} 


pid = getpid (); 
putenv ("TERM=linux"); 

//tty argv is passed in from inittab 
// as is in the fonn of ttyl 
mg_tty = argv[optind]; 

if (!mg_tty) 

printf("no tty"); 

if (stmcmp (mg_tty, "/dev/", 5) == 0) 
mg_tty += 5; 

trustedpath(REGISTER, pid); 
open tty (); 

// the primary trusted path decision loop 
for (;;) { 

int my_ret = 0; 

char menu_ret = NULL; 

switch (tp_state) { 

case NOJJSER: 

display_SAK_msg(); 

pause(); // wait for sak 

tp_state = IN_AUTH; // change state 

break; // break to next state 

case IN_AUTH: 

my_ret = tp_auth(); //authenticate the user 

if(my_ret) // authentication failed 
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else 


tp_state = NO_USER; 


tp_state = IN_TP_MENU; //change state 

break; // break to next state 

case IN_TP_MENU: 

menuret = do_tp_menu(); 

//start a new shell 
if (menu_ret =—s') { 

// check the current shell count 
if(num_open_sessions >=MAX_TP_SHELLS) { 

printf("There are too many open shells\n"); 
printf("Please close a shell to proceed\n"); 
sleep(3); 

} 

else{ 

tp_state = USER_RUN; 
tpopcnshclh); 

} 

break; 

} 


//quit a session 

else if(menu_ret == ’q') { 

// find out which session to end 
int my_session = 0; 
my_session = get_session_num(); 

// if there are no open sessions 
if (!my_session){ 

printf("There is no open session\n"); 
sleep(5); 

// don't change state eg stay in tp_menu 

} 

else { 


tp_tenninate_session(my_session); 
// check if that was the last session 
if(! num_open_sessions) { 

tp_state = NO_USER; 
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PAM_END; 

} 


break; 

} 

//resume a previous shell 
else if (menu_ret ==V) { 

current_session = get_session_num(); 
if(!current_session){ // no open session 

printf("There is no open session to restore\n"); 
break; 

} 

// restore the suspended processes 

trustedpath(RESTORE, sessions [currentsession- 

l].session_pid); 

switch_vt(sessions[current_session-l].session_tty); 
tp_state = USER_RUN; 

} 

break; 

case USER_RUN: 

//wait for a sak 
pause(); 

// after pause reactive tp menu 
// suspend user processes 

trustedpath(SUSPEND, sessions[current_session-l].session_pid); 

currentsession = 0; 

// switch to trusted path tty 
switch_vt(TP_VT); 

// reset state 

tp_state = INTPMENU; 
break; 


} //end switch 

} //end of endless loop — can i say that? 

} 
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// Terminates a single user session 
int tp_terminate_session(my_session) { 

// trusted path kill sys call 

trustedpath(KILL, (int) sessions[my_session-l].session_pid); 
sleep(l); 

// clean up the data structs 
delete_session(my_session); 

// need to close tty 

ioctl(sessions [my_session]. session_fd, 

VT_DISALLOCATE, sessions[my_session-l].session_tty); 
ioctl(sessions [my_session]. session_fd, 

VT_RELDISP, sessions[nry_session-l].session_tty); 

close(sessions[nry_session-1 ] .session_fd); 


return 0; 

} 

// tp_open_shell opens a virtual tenninal 
// and then creates a shell for the user 
// this code is derived from Jon Tomb's open 

int tp_open_shell(void){ 

// set up the new tty 
struct vt_stat vt; 
int fd = 0; 
int new_pid; 
int vtno = -1; 

char vtname[sizeof VTNAME + 2]; 

// we don’t have a tty selected 
if (vtno == -1) { 

// get a 'console' fd to query vt database 
if ((fd = open("/dev/console",O_WRONLY,0)) < 0) { 
perror("Failed to open /dev/console\n"); 
return(2); 

} 


// grab the next available vt 

if ((ioctl(fd, VT_OPENQRY, &vtno) < 0) || (vtno ==-!)) { 
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perror("Cannot find a free VT\n"); 

close(fd); 

return(3); 

} 


// get a handle to the vt state struct 
if (ioctl(fd, VTGETSTATE, &vt) < 0) { 
perror("can't get VTstateV); 
close(fd); 
return(4); 

} 

// unlock the vt switching functionality 

if (ioctl(fd, VTUNLOCKS WITCH, 256) < 0) { 
perror("Unable to unlock VT\n"); 
close(fd); 
return(5); 

} 

} 

sprintf(vtname, VTNAME, vtno); 

char my_tty[sizeof VTNAME +2]; 
sprintf(my_tty, "tty%d", vtno); 

// fork a new process to use for the 
// user terminal 
if((new_pid=fork()) == 0) { 

/* leave current vt */ 
signal(SIGINT, SIGDFL); 

// finish pam initialization 

// This will call the selinux pam module 

// which will set the context for the session 

retcode = pam_set_item(pamh, PAMRHOST, hostname); 

retcode = pam_set_item(pamh, PAMTTY, my tty); 

retcode = pam_open_session(pamh, 0); 
PAMFAILCHECK; 

retcode = pam_setcred(pamh, PAM ESTABLISH CRED); 
PAMFAILCHECK; 

//close the password database 
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endpwent(); 

//set the group id with the user's gid 
setgid(pwd->pw_gid); 

// if the user doesn't have a defined shell 

if(*pwd->pw_shell == '\0') pwd->pw_shell = PATHB SHELL; 

environ = (char**)malloc(sizeof(char*)); 
memset(environ, 0, sizeof(char*)); 

// set up the environment 
setenv("HOME", pwd->pw_dir, 0); 

if(pwd->pw_uid) 

setenv("PATH", PATH DEFPATH, 1); 

else 

setenv("PATH", PATHDEFPATHROOT, 1); 

setenv("SHELL", pwd->pw_shell, 1); 
setenv("LOGNAME", pwd->pw_name, 1); 


int i; 

env = pam_getenvlist(pamh); 

if (env != NULL) { 

for (i=0; env[i]; i++) { 
putenv(env[i]); 

} 

} 

if (setsid() < 0) { 

fprintf(stderr, "open: Unable to set new session\n"); 

} 


close(O); 

close(l); 

close(2); 

close(fd); 

// open the new vt 
// if this fails we can't tell anyone 
if ((fd = open(vtname, ORDWR)) == -1) { 
_exit (4); // silently die 
} 
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dup(fd); dup(fd); 


(void) ioctl(fd, VTACTIVATE, vtno); 

(void) ioctl(fd, VTWAIT ACTIVE, vtno); 

setuid(pwd->pw_uid); 

if (chdir(pwd->pw_dir) < 0) { 

printf(_("No directory %s!\n"), pwd->pw_dir); 

if (chdir("/")) 

exit(0); 

user_dir = 

printf(_("Logging in with home = Y'A'Vn")); 

} 


execlp("/bin/bash", "bash", NULL); 

} 

if ( new_pid < 0 ) { 

PAM_END; 

perror("open: fork() error"); 
return(6); 

} 

/* parent */ 

signal(SIGHUP, SIGIGN); 
signal(SIGINT, SIG IGN); 
signal(SIGQUIT, SIG IGN); 
signal(SIGTSTP, SIG IGN); 
signal(SIGTTIN, SIG IGN); 
signal(SIGTTOU, SIG IGN); 

// update our database 
add_session(vtno, new_pid, fd); 

// the num_open_sessions is incremented in add_session 
current_session = num_open_sessions; 

// wait a couple of sec then lock the tty 
sleep(l); 

ioctl(fd, VT LOCKSWITCH, 256); 
return 0; 
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// Switch between virtual tenninals 
// return zero if successful 
int switch_vt(vtno) { 

int fd; 

if ((fd = open("/dev/console",O_WRONLY,0)) < 0) { 
perror("Can’t open /dev/console\n"); 
return(3); 

} 

// unlock the vt switching functionality 
ioctl(fd, VTUNLOCKS WITCH, 256); 


if (ioctl(fd, VT ACTIVATE, vtno) < 0) { 

fprintf(stderr, "Failed to select VT %d (%s)\n", vtno, 
strerror(errno)); 
return(3); 

} 

// make sure we have switched 

(void) ioctl(fd, VTWAIT ACTIVE, vtno); 

// lock the vt switching functionality 
ioctl(fd, VT LOCKSWITCH, 256); 

return(O); 

} 

// display the trusted path menu 
// returns the selected value 
char do_tp_menu(){ 

char letter; 
int error = 0; 
clear_screen(); 
print_tp_menu(); 

do { 

letter = getchar(); 

error ++; 

if( error > 3) { 

clear_screen(); 
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print_tp_menu_error(); 
print_tp_menu(); 
error = 0; 

} 

} while ((letter != ’s') && (letter != 'q') && (letter != 'r')); 
return letter; 

} 

// a simplistic way to move everything 
// off the screen 
void clear_screen() { 
int i =0 ; 

for (i = 0; i < 50; i++) 
printf("\n"); 

} 

void print_tp_menu() { 

printf("Type s then hit enter to start a new shell\n"); 
printf("Type q then hit enter to quit a session\n"); 
printf("Type r then hit enter to resume a session\n"); 

} 

void print_tp_menu_error() { 

printf("you must select the letter s or q or r\n"); 

} 


void display_SAK_msg(void) { 

printf("\nPlease press the control and break key at the same time to 
begin\n"); 

} 

// This section is derived from login.c 

// 

// 2004-7-24 ahilchie@nps.navy.mi 

// using pam to authenticate the user 

int tp_auth() { 

char *tty_name; 

extern int optind; //used to grab tty from arg 
username = hostname = tty_name = NULL; 
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// set local environment, msg cat dir & gettext domain 
setlocale(LC_ALL,""); 
bindtextdomain(PACKAGE, LOCALEDIR); 
textdomain(P ACKAGE); 

setpgrp(); 

// start the pam auth procedure 

retcode = pam_start("login",username, &conv, &pamh); 

// bail out if we weren't able to talk with pam 
if(retcode != PAM_SUCCESS) { 

fprintf(stderr, _("login: PAM Failure, aborting: %s\n"), 
pam_strerror(pamh, retcode)); 
syslog(LOG_ERR, ("Couldn’t initialize PAM: %s"), 
pam_strerror(pamh, retcode)); 
exit(99); 

} 


// hostname is set to NULL 

retcode = pam_set_item(pamh, PAM RHOST, hostname); 
PAMFAILCHECK; 

// for root to be able to login the tty name 

// must be set to one of the devices 

// listed in /etc/securetty 

// mg_tty is the tty value in /etc/inittab 

retcode = pam_set_item(pamh, PAM TTY, mg tty); 

PAMFAILCHECK; 

// localize the user prompt 

retcode= pam_set_item(pamh, PAM USER PROMPT, ("Trusted Path 
login: ")); 

PAMFAILCHECK; 


int faileount=0; 

// set user name to null 

pam_set_item(pamh, PAM_USER, NULL); 

// the primary authentication loop 
retcode = pam_authenticate(pamh, 0); 
while((failcount++ < PAM MAX LOGIN TRIES) && 
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((retcode == PAMAUTHERR) || 

(retcode == PAM_USER_UNKNOWN) || 

(retcode == PAMCREDINSUFFICIENT) || 

(retcode == PAM AUTHINF0_UN A VAIL))) { 
pam_get_item(pamh, PAM_USER, (const void **) &username); 

syslog(LOG_NOTICE,_("FAILED LOGIN %d FROM %s FOR %s, 

%s"), 

failcount, hostname, username, pam_strerror(pamh, retcode)); 

fprintf(stderr,_("Login incorrect\n\n")); 
pam_set_item(pamh,PAM_USER,NULL); 
retcode = pam_authenticate(pamh, 0); 

} 


// if pam failed capture the reason 
if (retcode != PAM SUCCESS) { 
pam_get_item(pamh, PAM_USER, (const void **) &username); 

if (retcode == PAM MAXTRIES) 

syslog(LOG_NOTICE,_("TOO MANY LOGIN TRIES (%d) FROM 

%s FOR" 

"%s, %s"), failcount, hostname, username, 
pam_strerror(pamh, retcode)); 

else 

syslog(LOG_NOTICE, ("FAILED LOGIN SESSION FROM %s FOR 

%s, %s"), 

hostname, username, pam_strerror(pamh, retcode)); 

fprintf(stderr,_("\nLogin incorrect\n")); 

pam_end(pamh, retcode); 

exit(0); 

} 

retcode = pam_acct_mgmt(pamh, 0); 

// prompt the user to change password if it is time 
if(retcode == PAM NEW AUTHTOK REQD) { 

retcode = pam_chauthtok(pamh, 

PAMCHANGEEXPIREDAUTHTOK); 

} 

PAMFAILCHECK; 

// update the username 
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retcode = pam_get_item(pamh, PAM_USER, (const void **) 
&username); 

PAMFAILCHECK; 

// if something is wrong with user name — log it 
if (lusername || !*username) { 

fprintf(stderr, _("\nSession setup problem, abortAn")); 
syslog(LOG_ERR, _("NULL user name in %s:%d. Abort."), 

_FUNCTION_,_LINE_); 

pam_end(pamh, PAM_SYSTEM_ERR); 
exit(l); 

} 

if (!(pwd = getpwnam(usemame))) { 

fprintf(stderr, _("\nSession setup problem, abortAn")); 
syslog(LOG_ERR, _("Invalid user name \"%s\" in %s:%d. 

Abort."), 

username, _FUNCTION_, _LINE_); 
pam_end(pamh, PAM SYSTEM ERR); 
exit(l); 

} 

/* 

* Create a copy of the pwd struct - otherwise it may get 

* clobbered by PAM 

*/ 

memcpy(&pwdcopy, pwd, sizeof(*pwd)); 
pwd = &pwdcopy; 

pwd->pw_name = strdup(pwd->pw_name); 
pwd->pw_passwd = strdup(pwd->pw_passwd); 
pwd->pw_gecos = strdup(pwd->pw_gecos); 
pwd->pw_dir = strdup(pwd->pw_dir); 
pwd->pw_shell = strdup(pwd->pw_shell); 
if (!pwd->pw_name || !pwd->pw_passwd || !pwd->pw_gecos || 

!pwd->pw_dir || !pwd->pw_shell) { 
fprintf(stderr, _("login: Out of memory\n")); 
syslog(LOG_ERR, "Out of memory"); 
pam_end(pamh, PAM_SYSTEM_ERR); 
exit(l); 

} 

username = pwd->pw_name; 

// Initialize the supplementary group list. 

// This should be done before pam_setcred because 

// the PAM modules might add groups during pam_setcred. 

if (initgroups(usemame, pwd->pw_gid) < 0) { 
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syslog(LOG_ERR, "initgroups: %m"); 
fprintf(stderr, _("\nSession setup problem, abortAn")); 
pam_end(pamh, PAM_SYSTEM_ERR); 
exit(l); 

} 

return 0; 

} 


// a function to allow the user to select a session 
// if there is only one open session it returns w/o user input 
// return is the session number 
int get_session_num() { 
int re = 0; 
int temp =0; 
clear_screen(); 

//printf("in get session num and num open shells is: %d\n", 

// num_open_sessions); 

switch (num_open_sessions) { 

case 0: 

printf("There is not an open shell\n"); 

printf("Please select s to start a new shcll\n"); 

sleep(3); 

return re; 

break; 

case 1: 

return 1; 
break; 

default: 

while(!rc){ 

printf(" There are %d open sessions\n", 
num_open_sessions); 

printf("Enter a session number to select it\n"); 
char myinput; 
myinput = getchar(); 
temp = atoi(&my_input); 
if( temp > 0 && temp <= numopensessions) 
re = temp; 

printf("That selections is not valid\n"); 

} 

return re; 

} 

} 
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// error() - output error messages 
// direct copy from mingetty 
static void error (const char *fmt,...) 

{ 

va_list va_alist; 
va_start (va_alist, fmt); 

openlog (progname, LOGPID, LOGAUTH); 
vsyslog (LOGERR, fmt, va alist); 

/* no need, we exit anyway: closelog (); */ 
va_end (va_alist); 
sleep (5); 

exit (EXITFAILURE); 

} 

// open_tty - set up tty as standard { input, output, error } 

// direct copy from mingetty 
static void open_tty (void) 

{ 

struct sigaction sa, sa_old; 
char buf[40]; 
int fd; 

/* Set up new standard input. */ 
if (mg_tty[0] =='/') 

strcpy (buf, mg_tty); 

else { 

strcpy (buf, "/dev/"); 
strcat (buf, mg_tty); 

} 

/* There is always a race between this reset and the call to 
vhangup() that s.o. can use to get access to your tty. */ 
if (chown (buf, 0, 0) || chmod (buf, 0600)) 
if (errno != EROFS) 

error ("%s: %s", mg_tty, strerror (errno)); 

sa.sahandler = SIGIGN; 
sa.sa_flags = 0; 
sigemptyset (&sa.sa_mask); 
sigaction (SIGHUP, &sa, &sa_old); 

/* vhangup() will replace all open file descriptors in the kernel 
that point to our controlling tty by a dummy that will deny 
further reading/writing to our device. It will also reset the 
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tty to sane defaults, so we don’t have to modify the tty device 
for sane settings. We also get a SIGHUP/SIGCONT. 

*/ 

if ((fd = open (buf, ORDWR, 0)) < 0) 

error ("%s: cannot open tty: %s", mg_tty, strerror (ermo)); 
if (ioctl (fd, TIOCSCTTY, (void *) 1) = -1) 

error ("%s: no controlling tty: %s", mg_tty, strerror (ermo)); 
if (lisatty (fd)) 

error ("%s: not a tty", mg_tty); 


if (nohangup == 0) { 
if (vhangup ()) 

error ("%s: vhangup() failed", mg_tty); 

/* Get rid of the present stdout/stderr. */ 

close (2); 

close (1); 

close (0); 

close (fd); 

if ((fd = open (buf, O RDWR, 0)) != 0) 

error ("%s: cannot open tty: %s", mg_tty, 
strerror (ermo)); 

if (ioctl (fd, TIOCSCTTY, (void *) 1) == -1) 

error ("%s: no controlling tty: %s", mg_tty, 
strerror (ermo)); 


} 

/* Set up stdin/stdout/stderr. */ 

if (dup2 (fd, 0) != 0 || dup2 (fd, 1) != 1 || dup2 (fd, 2) != 2) 
error ("%s: dup2(): %s", mg_tty, strerror (errno)); 
if (fd > 2) 

close (fd); 

/* Write a reset string to the terminal. This is very linux-specilic 
and should be checked for other systems. */ 
if (noclear == 0) 

write (0, "\033c", 2); 


sigaction (SIGHUP, &sa_old, NULL); 

} 

// handle the user 1 signal that the kernel 
// sends to notify the trusted path of the SAK 
void tp_signal_catcher(int the_sig){ 
if (the_sig == SIGUSR1){ 
return; 

} 

} 
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// adds a user session to the sessions array 
void add_session(int new_tty, int new_pid, int new_fd){ 
sessions[num_open_sessions].session_tty = new_tty; 
sessions[num_open_sessions].session_pid = new_pid; 
sessions[num_open_sessions].session_fd = new_fd; 
num_open_sessions ++; 

} 

// remove a user session from the sessions array 
void delete_session(int session_num){ 

//validate the session_num 
if (sessionnum > numopensessions) { 

printf("the session number is too large\n"); 
return; 

} 

if (session num < 0){ 

printf("the session number is too small\n"); 
return; 

} 

//careful the array is zero indexed 
int arrayindex = session num - 1; 

//simple case first 

if (array_index == (num_open_sessions - 1)){ 

// sort of redundent but... 
sessions[session_num].session_tty = 0; 
sessions[session_num].session_pid = 0; 
sessions[session_num].session_fd = 0; 
numopensessions —; 

} 

else { 

int loopcounter = array index; 
loopcounter ++; 

while (loopcounter <= num open sessions) { 
//move the info up a slot 
sessions [loopcounter-1 ]. session tty = 
sessions [loopcounter], session_tty; 
sessions [loopcounter-1 ]. session_pid = 
sessions [loopcounter]. session_pid; 
sessions [loopcounter-1 ]. session fd = 
sessions [loopcounter]. session fd; 
loopcounter++; 

} 

numopensessions —; 

} 

} 
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APPENDIX B. TRUSTED PATH - KERNEL 


These two files, trustedpath.h and trustedpath.c are the kernel portions of the 
trusted path. Additional kernel modifications were necessary for the project and are 
documented in the other appendices. 

trustedpath.h 

#ifndef_L1NUXTRUSTEDPATHH 

#define_L1NUXTRU S TEDP ATHH 

/* include/linux/trustedpath.h 

* 

* ver 1 ahilchie 6-14-04 

* 

* Demo implementation of Trusted Path for SELinux 

* 

* based on the magic system request key 

*/ 

#include <linux/config.h> 

#include <linux/linkage.h> 

#include <linux/sched.h> 

#define REGISTER 0 
#define SUSPEND 1 
#define RESTORE 2 
#define KILL 3 

struct pt_regs; 
struct tty_struct; 

/* Trusted Path interface 

*/ 

void handle_trustedpath( struct pt_regs *, struct tty_struct *); 
void send_sak_sig(void); 
int suspend_all_processes( int user_pid); 
int restore_all_processes(int pid); 

#endif 
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trustedpath.c 


// drivers/char/trustedpath.c 
// ver 1 ahilchie 6-14-04 

// Demo implementation of Trusted Path for SELinux 

#include <linux/config.h> 

#include <linux/sched.h> 

#include <linux/interrupt.h> 

#include <linux/mm.h> 

#include <linux/fs.h> 

#include <linux/tty.h> 

#include <linux/mount.h> 

#include <linux/kdev_t.h> 

#include <linux/major.h> 

#include <linux/trustedpath.h> 

#include <linux/kbd_kern.h> 

#include <linux/quotaops.h> 

#include <linux/kernel.h> 

#include <linux/module.h> 

#include <linux/suspend.h> 

#include <linux/writeback.h> 

#include <linux/buffer_head.h> 

#include <asm/ptrace.h> 

#include <linux/bst.h> 

//#include <sys/syscall.h> 

//#include <asm/uaccess.h> 


unsigned long lasttptime = 0; 
unsigned long tp delay = 1; 

//extern void *sys_call table[]; 

//int uid; 

//asmlinkage int( * getuid_call)(); 

// trusted path userspace module pid 
// this is the only process we will accept 
// system calls from 
// by default we trust init's parent 
int tpum = 0; 

// lock will be set to one after the first 
// registration of the user space trusted path 
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// this will prevent new processes trying to 
// pretend to be the trusted path 
int lock = 0; 

// Notify the trusted path in user space that a SAK has arrived 
void send_sak_sig() { 

// test to make sure tpum is registered 
if (tpum ==0){ 

printk(KERN_CRIT "Received SAK prior to Trusted Path registering"); 


else { 

struct taskstruct *p; 
p = find_task_by_pid(tpum); 
force_sig(SIGUSRl, p); 

} 

} 

// Handle the SAK notification from keyboard.c 
// The trusted path state is maintained in userspace 
// so all the kernel does is signal the trusted path 

void handle_trustedpath( struct pt_regs *pt_rcgs, struct tty_struct *tty){ 

// hack to stop multiple responses to single keystroke 
if (get_seconds() <= last_tp_time + tp_delay) 
return; 

last_tp_time = get_seconds(); 
send_sak_sig(); 

} 

// Another helper funtion to suspend processes associated 
// with a user pid 

// It is a little clunky because we are receiving an int 

// not a task_struct from user space. Therefore we end up cycling 

// through all the processes 

int suspend_all_processes( user_pid) { 

int usertpid =0; 
struct task struct *p; 

int my_tty =0; 

// enumerate all the processes 
for_each_process(p) { 
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//printk(KERN_CRIT "PID is %d and TPID is %d \n", p->pid, p->tp_id); 


// identify the process user_pid 
if(p->pid == user_pid) { 


//get the trusted path id of the user_pid 
usertpid = p->tp_id; 
iny tty = (int) p->tty; 

} 

} 

// test to make sure that we did find a user_tp_id 
if (luser tp id) return -1; 

// user_tp_id now contains the correct number 
// user_pid is the trusted path pid 
for_each_process(p) { 

// if p has the correct tp id 
if(p->tp_id == usertpid) { 

//printk(KERN_CRIT "Bingo on pid %d\n", p->pid); 
suspend_task(p); 


} 

} 

// test routine to visualize the status of all the processes 

/*{ 

printk(KERN_CRIT "Suspend debug routine\n"); 
for_each_process(p) { 

// int my_rq; 

// myrq = task_rq(p); 

printk(KERN_CRIT "pid=%d do_not_activate=%d \n", 
p->pid, p->do_not_activate); 

} 

}*/ 

return 0; 

} 

// Takes an int that is the pid of the trusted path 

// gets the tp id and restores all processes with that tp id 

// except the trusted path 

int restore_all_processes( user_pid) { 


78 



int usertpid =0; 
struct task struct *p; 

// find the tp id of user_pid 
for_each_process(p) { 

// printk(KERN_CRIT "PID is %d and TP_ID is %d \n", 

//p->pid, p->tp_id); 
if(p->pid == user_pid) { 
usertpid = p->tp_id; 

//printk(KERN_CRIT "user tp id is %d\n", user_tp_id); 

} 

} 

//test to make sure we were able to find the tp id 
if(! user tp id) 
return -1; 

// restore all the processes with that tp id 
for_each_process(p) { 

// if p has the correct tp id 
if(p->tp_id == usertpid)) 
resume_task(p); 

} 

} 

// test routine to visualize the status of all the processes 

/* { 

printk(KERN_CRIT "Restore debug routine\n"); 
for_each_process(p) { 

// int my_rq; 

// myrq = task_rq(p); 

printk(KERN_CRIT "pid=%d do_not_activate=%d \n", p->pid, p- 
>do_not_activate); 

} 

}*/ 

return 0; 

} 

// helper function to kill all the processes associated 
// a session 

void kill_all_processes(int user_pid) { 
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int usertpid =0; 
struct task struct *p; 

// enumerate all the processes 
for_each_process(p) { 

// identify the process user_pid 
if(p->pid == user_pid) { 

//get the trusted path id of the user_pid 
usertpid = p->tp_id; 

//printk(KERN_CRIT "user tp id is %d\n", user_tp_id); 

} 

} 

// terminate each process with the tp id 
for_each_process(p) { 

//printk(KERN_CRIT "PID is %d tp id is %d\n", 

// p->pid, p->tp_id); 

// if p has the correct tp id 
if(p->tp_id == user_tp_id){ 

// printk(KERN_CRIT "Bingo on pid %d\n", p->pid); 
printk(KERN_CRIT "tenninating pid %d\n", p->pid); 
force_sig(SIGKILL, p); 

} 

} 

} 

asmlinkage int sys_trustedpath(int type_msg, int pid) { 

printk(KERN_CRIT "Pid %d called tp\n", current->pid); 
switch (type_msg) { 

case REGISTER: 

// set the lock after the first registration 
// there could be some potential problems 
// e.g. if the trusted path dies we would 
// have to reboot 
if (! lock) { 

tpum = pid; 
lock = 1; 

printk(KERN_CRIT 

"Trusted path registerd for pid %i\n" 

, pid); 
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break; 


case SUSPEND: 

if (current->pid == tpum){ 

suspend_all_processes(pid); 
printk(KERN_CRIT "tp suspend\n"); 

} 

break; 

case RESTORE: 

if (current->pid == tpum){ 

restore_all_processes(pid); 
printk(KERN_CRIT "tp restore\n"); 

} 

break; 
case KILL: 

if (current->pid == tpum){ 

kill_all_processes(pid); 
printk(KERN_CRIT "tp kill\n"); 

} 

break; 

default: 

printk(KERN_CRIT "incorrect trusted path syscall\n"); 

} 

return(O); 

} 

EXPORTSYMBOL(handletrustedpath); 
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APPENDIX C. TRUSTED PATH SYSTEM CALL 


This appendix provides detailed implementation information for the trusted path 
system call. 


Adding the interrupt 

In the arch/i386/kernel/entry.S file add at line 1040 
/* system call for the trusted path 
* ahilchie 7-12-04 

*/ 

.long sysjxustedpath /* 274 */ 

Adding the stub 

In the include/asm-i386/unistd.h file add at line 282 

#define_NR_trustedpath 274 

at line 284 increment the number of valid syscalls 
#define NR_syscalls 275 

Modifications to trustedpath.h 

Added access to the system call macro file. 

#include <linux/linkage.h> 

#define REGISTER 0 
#define SUSPEND 1 
#define RESTORE 2 
#define KILL 3 

Modifications to trustedpath.c 

/* handle trusted path system calls */ 

asmlinkage int sys_trustedpath( int type_msg, int user_pid) { 

switch (type_msg) { 

case REGISTER: 

break; 

case SUSPEND: 
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break; 

case RESTORE: 

break; 
case KILL: 

break; 

default: 


} 

return(O); 


User space header to support the system call 

Userspace.h 

#define REGISTER 0 
#define SUSPEND 1 
#define RESTORE 2 
#definc KILL 3 

#include <linux/unistd.h> 

_syscall2(int, trustedpath, int, type_msg, int, user_pid); 
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APPENDIX D. SCHEDULE MODIFICATION 


This appendix contains the modifications made to the sched.h and sched.c files in 
the kernel source tree. Code added as part of this work is in bold face. 

sched.h 

Due to the size of the original files, only the process table is presented. 

The process table, task_struct, was modified to include a new integer process ID 
for use by the trusted path. This is labeled as tpid and is used to detennine the original 
parent of processes. 

struct task_struct { 

volatile long state; /*-1 unrunnable, 0 runnable, >0 stopped*/ 
struct thread info *thread_info; 
atomic_t usage; 

unsigned long flags; /* per process flags, defined below */ 
unsigned long ptrace; 

int lock_depth; /* Lock depth */ 

int prio, static_prio; 
struct listhead run list; 
prio_array_t * array; 

/* DJS - Flag to control the activation of suspended tasks */ 
int do not activate; 

unsigned long sleep_avg; 
long interactive credit; 
unsigned long long timestamp; 
int activated; 

unsigned long policy; 

cpumask_t cpus allowed; 

unsigned int time_slice, first_time_slice; 

struct list head tasks; 

struct list head ptrace children; 

struct list head ptrace list; 

struct mmstruct *mm, *active_mm; 
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/* task state */ 

struct linuxbinfmt *binfmt; 
int exitcode, exit signal; 

int pdeath_signal; /* The signal sent when the parent dies */ 

/* ??? */ 

unsigned long personality; 
int did_exec:l; 
pidt pid; 

pid t_pgrp; /* Accessed via process_group() */ 

pid t tty_old_pgrp; 
pid t session; 
pidt tgid; 


// trusted path id -- tpid 
// ahilchie 6-16-04 

// the true parent pid of this process 

// to allow finding all the processes associated with a user 


pid t tp id; 

/* boolean value for session group leader */ 
int leader; 

/* 

* pointers to (original) parent process, youngest child, younger sibling, 

* older sibling, respectively. (p->father can be replaced with 

* p->parent->pid) 

*/ 

struct task_struct *real_parent; /* real parent process (when being 
debugged)*/ 

struct task_struct *parent; /* parent process */ 
struct list_head children; /* list of my children */ 

struct list_head sibling; /* linkage in my parent's children list */ 

struct task_struct *group_leader; /* threadgroup leader */ 

/* PID/PID hash table linkage. */ 
struct pidlink pids[PIDTYPE_MAX]; 


waitqueueheadt waitchldexit; 
struct completion *vfork_done; 

int user *set_child_tid; 

int user *clear_child_tid; 


/* for wait4() */ 

/* for vfork() */ 

/* CLONE CHILD SETTID */ 

/* CLONE CHILD CLEARTID */ 


unsigned long rt_priority; 

unsigned long it_real_value, it_prof_value, it_virt_value; 
unsigned long it real incr, it_prof_incr, it virt incr; 
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struct timerlist realtimer; 

struct list head posix timers; /* POSIX.lb Interval Timers */ 
unsigned long utime, stime, cutime, cstime; 

unsigned long nvcsw, nivcsw, cnvcsw, cnivcsw; /* context switch counts 

*/ 

u64 start_time; 

/* mm fault and swap info: this can arguably be seen as either mm-specific or 
thread-specific */ 

unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap; 

/* process credentials */ 

uidt uid,euid,suid,fsuid; 
gid t gid,egid,sgid,fsgid; 
struct group info *group_info; 

kemelcapt cap effective, cap inheritable, cap_pennitted; 
int keepcapabilities: 1; 
struct user_struct *user; 

/* limits */ 

struct rlimit rlim[RLIM_NLIMITS]; 
unsigned short used math; 
char comm[16]; 

/* file system info */ 

int link count, total link count; 
struct tty_struct *tty; /* NULL if no tty */ 

/* ipc stuff */ 

struct sysv_sem sysvsem; 

/* CPU-specific state of this task */ 
struct thread struct thread; 

/* filesystem information */ 
struct fs_struct *fs; 

/* open file information */ 

struct files_struct * files; 

/* namespace */ 

struct namespace *namespace; 

/* signal handlers */ 

struct signal_struct *signal; 
struct sighand struct *sighand; 

sigset t blocked, real blocked; 
struct sigpending pending; 

unsigned long sas_ss_sp; 
size_t sas_ss_size; 
int (*notifier)(void *priv); 
void *notifier_data; 
sigset_t *notifier_mask; 


87 



/* TUX state */ 
void *tux_info; 
void (*tux_exit)(void); 


void *security; 

struct auditcontext *audit_context; 

/* Thread group tracking */ 
u32 parent_exec_id; 
u32 self_exec_id; 

/* Protection of (de-)allocation: mm, files, fs, tty */ 
spinlockt alloc lock; 

/* Protection of proc dentry: nesting proc lock, dcache lock, 

write_lock_irq(&tasklist_lock); */ 
spinlock_t proclock; 

/* context-switch lock */ 

spinlock t switch_lock; 

/* journalling filesystem info */ 
void *journal_info; 

/* VM state */ 

struct reclaim state *reclaim_state; 

struct dentry *proc_dentry; 

struct backing dev info *backing_dev_info; 

struct io context *io_context; 

unsigned long ptrace_message; 
siginfo_t *last_siginfo; /* For ptrace use. */ 

}; 


// ahilchie trusted path mod by DJS 
void suspend_task(struct task_struct *p); 
void resume_task(struct task_struct *p); 

sched.c 

Only the functions that were modified are presented 

struct runqueue { 

spinlock_t lock; 

unsigned long long nr_switches; 

unsigned long nr running, expired timestamp, nr uninterruptible, 
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timestamplasttick; 

/* DJS - keep track of how many tasks are suspended */ 
unsigned long nrsuspend; 

task_t *curr, *idle; 

struct mmstruct *prev_mm; 

prio_array_t ^active, * expired, arrays[2]; 

/* DJS - Here is where we keep the suspended tasks */ 

prio array t *suspend_active,*suspend_expired, suspend arrays[2]; 

int best_expired_prio, prev_cpu_load[NR_CPUS]; 

#ifdef CONFIG_NUMA 

atomict *node_nr_running; 

int prev_node_load[MAX_NUMNODES]; 

#endif 

task_t *migration_thread; 
struct listhead migrationqueue; 

atomic t nr iowait; 


/* DJS - macros for handling the nr suspend counters */ 

/* DJS - Hhmmm - why wasn't nr running initiailzed to zero? */ 

# define nr suspend init(rq) do { (rq)->nr_suspend=0; } while (0) 

# define nr suspend inc(rq) do { (rq)->nr_suspend++; } while (0) 

# define nr suspend dec(rq) do { (rq)->nr_suspend—; } while (0) 

/* 

* _activate task - move a task to the runqueue. 

*/ 

static inline void_activate_task(task_t *p, runqueue t *rq) 

{ 

/* DJS - Only activate if were allowed (e.g. it is not suspended) */ 
if (!p->do_not_activate) { 

enqueue_task(p, rq->active); 
nrrunninginc(rq); 

} 

} 

/* DJS - New function to suspend a task */ 

/* 

* suspend task - move a task from the active/expired arrays 

* to the suspend active/suspend expire arrays 

*/ 

//static inline 

void suspend_task(struct task struct *p) //, runqueue t *rq) 

{ 
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int is_active=l; 

// ahilchie added 
struct runqueue *rq; 
rq = taskrq(p); 

if(p->array) 

{ 

/* DJS - determine if the task is active or expired */ 
if (p->array == rq->expired) 
is_active=0; 
nrrunningdec(rq); 

dequeue_task(p, p->array); 
if (isactive) { 

enqueue_task(p, rq->suspend_active); 

}else{ 

enqueue_task(p, rq->suspend_expired); 

} 

nrsuspendinc(rq); 

}else{ 

// Mark the task so it doesn't get activated 
p->do_not_activate = 1; 

} 

} 

/* DJS - New function to resume a suspended a task */ 

/* 

* resume task - move a task from the suspend active/suspend expired arrays 

* to the active/expire arrays 

*/ 

//static inline 

void resume_task(struct task struct *p)//, runqueue t *rq) 

{ 

int is_active=l; 

// ahilchie added 
struct runqueue *rq; 
rq = taskrq(p); 

if(p->array) 

{ 

/* DJS - determine if the task is active or expired */ 
if (p->array == rq->suspend_expired) 
is_active=0; 
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nrsuspenddec(rq); 
dequeue_task(p, p->array); 
if (isactive) { 

enqueue_task(p, rq->active); 

}else{ 

enqueue_task(p, rq->expired); 

} 

nrrunninginc(rq); 

}else{ 

// Mark the task so it can get activated 
p->do_not_activate = 0; 

} 

} 

static int try_to_wake_up(task_t * p, unsigned int state, int sync) 

{ 

unsigned long flags; 
int success = 0; 
long oldstate; 
runqueue t *rq; 

repeat lock task: 

rq = task_rq_lock(p, &flags); 
oldstate = p->state; 
if (old_state & state) { 
if (!p->array) { 

/* 

* Fast-migrate the task if it's not running or runnable 

* currently. Do not violate hard affinity. 

*/ 

if (unlikely(sync && !task_running(rq, p) && 

(task_cpu(p) != smp_processor_id()) && 
cpu_isset(smp_processor_id(), 

p->cpus_allowed) && 

! cpu_is_offline(smp_processor_id()))) { 
set_task_cpu(p, smp_processor_id()); 
task_rq_unlock(rq, &flags); 
goto repeat lock task; 

} 

if (old state == TASK_UNINTERRUPTIBLE) { 
rq->nr_uninterruptible—; 

/* 

* Tasks on involuntary sleep don’t earn 

* sleep_avg beyond just interactive state. 

*/ 
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p->activated = -1; 


} 

if (sync && (task_cpu(p) == smp_processor_id())) 
_activate_task(p, rq); 

else { 

activate_task(p, rq); 
if (TASK_PREEMPTS_CURR(p, rq)) 
resched_task(rq->curr); 

} 

success = 1; 

} 

/* DJS - Only change the state if it is in a runqueue */ 
if (p->array) { 

p->state = TASK RUNNING; 

} 

} 

task_rq_unlock(rq, &flags); 
return success; 


void fastcall wake_up_forked_process(task_t * p) 

{ 

unsigned long flags; 

runqueue t *rq = task_rq_lock(current, &flags); 

BUG_ON(p->state != TASK_RUNNING); 

/* 

* We decrease the sleep average of forking parents 

* and children as well, to keep max-interactive tasks 

* from forking tasks that are max-interactive. 

*/ 

current->sleep_avg = JIFFIES_TO_NS(CURRENT_BONUS(current) * 

PARENT_PENALTY / 100 * MAXSLEEPA VG / MAX_BONUS); 

p->sleep_avg = JIFFIES_TO_NS(CURRENT_BONUS(p) * 

CHILD PENALTY / 100 * MAX SLEEP AVG / MAX_BONUS); 

p->interactive_credit = 0; 

p->prio = effective_prio(p); 
set_task_cpu(p, smp_processor_id()); 

if (unlikely(!current->array)) 
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activate_task(p, rq); 


else { 

/* DJS - Only add it, if it is not suspended */ 
if (!p->do not activate) { 

p->prio = current->prio; 

list_add_tail(&p->run_list, &current->run_list); 
p->array = current->array; 
p->array->nr_active++; 
nrrunninginc(rq); 

} 

} 

task_rq_unlock(rq, &flags); 

} 


void_init sched init(void) 

{ 

runqueue t *rq; 
int i, j, k; 

for (i = 0; i < NR_CPUS; i++) { 
prio_array_t * array; 

rq = cpu_rq(i); 
rq->active = rq->arrays; 
rq->expired = rq->arrays + 1; 

/* DJS - init the suspend arrays */ 

rq->suspend_active = rq->suspend_arrays; 
rq->suspend_expired = rq->suspend_arrays + 1; 

rq->best_expired_prio = MAXPRIO; 

spin_lock_init(&rq->lock); 

INITLIS THE AD(&rq->migration_queue); 
atomic_set(&rq->nr_iowait, 0); 
nrrunninginit(rq); 


for (j = 0; j < 2; j++) { 

array = rq->arrays + j; 

for (k = 0; k < MAX_PRIO; k++) { 

INIT_LIST_HEAD(array->queue + k); 
_clear_bit(k, array->bitmap); 


} 


} 

// delimiter for bitsearch 
_set_bit(MAX_PRIO, array->bitmap); 
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/* DJS - more init of the suspend arrays */ 
nrsuspendinit(rq); 
for (j = 0; j < 2; j++) { 

array = rq->suspend_arrays + j; 
for (k = 0; k < MAX PRIO; k++) { 

INIT_LIST_HEAD(array->queue + k); 
_clear_bit(k, array->bitmap); 

} 

// delimiter for bitsearch 
_set_bit(MAX_PRIO, array->bitmap); 

} 

} 

/* 

* We have to do a little magic to get the first 

* thread right in SMP mode. 

*/ 

rq = this_rq(); 
rq->curr = current; 
rq->idle = current; 

/* DJS - make sure we can activate it */ 
current->do_not_activate = 0; 

set_task_cpu(current, smp_processor_id()); 
wake_up_forked_process(current); 

init_timers(); 

/* 

* The boot idle thread does lazy MMU switching as well: 

*/ 

atomic_inc(&init_mm.mm_count); 
enter_lazy_tlb(&init_mm, current); 
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APPENDIX E. KEYBOARD DRIVER MODIFICATIONS 


This appendix contains the modification to the keyboard driver for the SELinux 
trusted path. For the sake of understandability the entire kbd keycode function, which 
contains the additional trusted path code, is provided. Code added as part of this work is 
in bold face. 


void kbd_keycode(unsigned int keycode, int down, struct pt_regs *regs) 

{ 

struct vc_data *vc = vc_cons[fg_console].d; 
unsigned short keysym, *key_map; 
unsigned char type, raw_mode; 
struct tty_stract *tty; 
int shift final; 

if (down != 2) 

add_keyboard_randomness((keycode « 1) A down); 

tty = vc->vc_tty; 

if (tty && (!tty->driver_data)) { 

/* No driver data? Strange. Okay we fix it then. */ 
tty->driver_data = vc; 

} 

kbd = kbdtable + fgconsole; 

if (keycode == KEYLEFTALT || keycode == KEY RIGHTALT) 
sysrq_alt = down; 

#if defined(CONFIG_SPARC32) || defined(CONFIG_SPARC64) 
if (keycode == KEY STOP) 

sparcllastate = down; 

#endif 


rep = (down == 2); 

#ifdef C ONF IG_M ACEMUMOUSEB TN 

if (mac_hid_mouse_emulate_buttons( 1, keycode, down)) 
return; 

#endif /* CONFIG MAC EMUMOUSEB TN */ 


if ((raw mode = (kbd->kbdmode == VC RAW))) 
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if (emulate_raw(vc, keycode, !down « 7)) 
if (keycode < BTN_MISC) 

printk(KERN_WARNING "keyboard, c: can't 
emulate rawmode for keycode %d\n", keycode); 

/ 

* ahilchie trusted path 6-13-0 

* 

* catch the trusted path SAK and notify the 

* kernel trusted path modul 


if (keycode == KEY LEFTCTRL || keycode == KEY RIGHTCTRL) 
tpctrl = down; 

if(keycode == KEY PAUSE && tp Ctrl){ 
handle_trustedpath(regs, tty); 
return; 


#ifdef CONFIGMAGICSYSRQ /* Handle the SysRq Hack */ 

if (keycode == KEY_SYSRQ && (sysrq_down || (down == 1 && 

sysrq_alt))) { 

sysrq_down = down; 
return; 

} 

if (sysrq_down && down && !rep) { 

handle_sysrq(kbd_sysrq_xlate[keycode], regs, tty); 
return; 


#endif 

#if defined(CONFIG_SPARC32) || defined(CONFIG_SPARC64) 
if (keycode == KEY_A && sparc_ll_a_state) { 
sparcllastate = 0; 
sun_do_break(); 

} 

#endif 

if (kbd->kbdmode == VC MEDIUMRAW) { 

/* 

* This is extended medium raw mode, with keys above 127 

* encoded as 0, high 7 bits, low 7 bits, with the 0 bearing 

* the 'up' flag if needed. 0 is reserved, so this shouldn’t 

* interfere with anything else. The two bytes after 0 will 

* always have the up flag set not to interfere with older 
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* applications. This allows for 16384 different keycodes, 

* which should be enough. 

*/ 

if (keycode < 128) { 

put_queue(vc, keycode | (!down « 7)); 

} else { 

put_queue(vc, !down « 7); 
put_queue(vc, (keycode » 7) | 0x80); 
put_queue(vc, keycode | 0x80); 

} 

rawmode = 1; 

} 

if (down) 

set_bit(keycode, key_down); 

else 

clear_bit(keycode, key_down); 

if (rep && (!vc_kbd_mode(kbd, VC_REPEAT) || (tty && 

(!L_ECHO(tty) && tty->driver->chars_in_buffer(tty))))) { 

/* 

* Don’t repeat a key if the input buffers are not empty and the 

* characters get aren't echoed locally. This makes key repeat 

* usable with slow applications and under heavy loads. 

*/ 

return; 

} 

shiftfinal = (shift_state | kbd->slockstate) A kbd->lockstate; 
key_map = key_maps[shift_final]; 

if (!key_map) { 

compute_shiftstate(); 
kbd->slockstate = 0; 
return; 

} 

keysym = key_map [keycode]; 
type = KTYP(keysym); 

if (type < OxfO) { 

if (down && !raw_mode) to_utf8(vc, keysym); 
return; 

} 


97 



type -= OxfO; 


if (raw mode && type != KTSPEC && type != KT SHIFT) 
return; 

if (type == KTLETTER) { 
type = KT_LATIN; 

if (vc_kbd_led(kbd, VC CAPSLOCK)) { 

key map = kcytnaps [sh i ft_li na 1 A (1 « KG SHIFT)]; 
if (key_map) 

keysym = key_map[keycode]; 

} 

} 

(*k_handler[type])(vc, keysym & Oxff, !down, regs); 

if (type != KT SLOCK) 

kbd->slockstate = 0; 

} 
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APPENDIX F. FORK MODIFICATION 


This appendix contains the modification made to the fork.c file in the kernel 
source tree. Code added as part of this work is in bold face. Due to the size of the 
original files, only the process copy, copyjprocess, function is presented. The copy 
process is called during the creation of all processes except for the original process init. 

The modification sets the trusted path identifier, tp_id, to the tp_id of its parent 
process unless it’s parent is init, e.g., process ID 1, in which case the tp id is set to the 
current process ID. Since init will start the getty process each time each session has a 
single unique tp_id that is not modified during the course of execution. 

struct task_struct *copy_process(unsigned long clone_flags, 

unsigned long stack_start, 
struct pt_regs *regs, 
unsigned long stack_size, 

int user *parent_tidptr, 

int user *child_tidptr) 

{ 

int retval; 

struct task_struct *p = NULL; 

if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) 

(CLONE_NEWNS|CLONE_FS)) 

return ERRPTR(-EINVAL); 


/* 

* Thread groups must share signals as well, and detached threads 

* can only be started up within the thread group. 

*/ 

if ((clone_flags & CLONE_THREAD) && !(clone_flags & 
CLONE_SIGHAND)) 

return ERRPTR(-EINVAL); 


/* 

* Shared signal handlers imply shared VM. By way of the above, 

* thread groups also imply shared VM. Blocking this case allows 

* for various simplifications in other code. 

*/ 

if ((clone_flags & CLONE_SIGHAND) && !(clone_flags & 
CLONE YM)) 
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return ERRPTR(-EINVAL); 

retval = security_task_create(clone_flags); 
if (retval) 

goto forkout; 

retval = -ENOMEM; 

P = duptaskstruct(current); 

if Op) 

goto fork out; 
p->tux_info = NULL; 

retval = -E AGAIN; 

if (atomic_read(&p->user->processes) >= 

p->rlim[RLIMIT_NPROC] .rlimcur) { 
if (! capable(C AP_S Y S_ADMIN) 

!capable(CAP_SYS_RESOURCE) && 

p->user != &root_user) 
goto bad fork free; 

} 

atomic_inc(&p->user->_count); 

atomic_inc(&p->user->processes); 

get_group_info(p->group_info); 

/* 

* If multiple threads are within copy_process(), then this check 

* triggers too late. This doesn't hurt, the check is only there 

* to stop root fork bombs. 

*/ 

if (nr threads >= maxthreads) 

goto badforkcleanupcount; 

if (! try_module_get(p->thread_info->exec_domain->module)) 
goto bad fork cleanup count; 

if (p->binfmt && !try_module_get(p->binfmt->module)) 
goto bad_fork_cleanup_put_domain; 


p->did_exec = 0; 
copy-flagstclone-flags, p); 
if (clone flags & CLONE IDLETASK) 
p->pid = 0; 

else { 

p->pid = alloc_pidmap(); 


&& 
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if (p->pid == -1) 

goto badforkcleanup; 

} 

retval = -EFAULT; 

if (clone_flags & CLONEPARENTSETTID) 
if (put_user(p->pid, parent tidptr)) 
goto bad fork cleanup; 

p->proc_dentry = NULL; 

INIT_LIST_HEAD(&p->children); 

INIT_LIST_HEAD(&p->sibling); 

INIT_LISTHEAD(&p->posix_timers); 

init_waitqueue_head(&p->wait_chldexit); 

p->vfork_done = NULL; 

spin_lock_init(&p->alloc_lock); 

spin_lock_init(&p->proc_lock); 

clear_tsk_thread_flag(p, TIF SIGPENDING); 
init_sigpending(&p->pending); 

p->it_real_value = p->it_virt_value = p->it_prof_value = 0; 
p->it_real_incr = p->it_virt_incr = p->it_prof_incr = 0; 
init_timer(&p->real_timer); 
p->real_timer.data = (unsigned long) p; 

p->leader = 0; /* session leadership doesn’t inherit */ 

p->tty_old_pgrp = 0; 
p->utime = p->stime = 0; 
p->cutime = p->cstime = 0; 
p->lock_depth = -1; /* -1 = no lock */ 

p->start_time = getjiffies_64(); 
p->security = NULL; 
p->io_context = NULL; 
p->audit_context = NULL; 

retval = -ENOMEM; 
if ((retval = security_task_alloc(p))) 
goto bad fork cleanup; 
if ((retval = audit_alloc(p))) 

goto bad fork cleanup security; 

/* copy all the process information */ 
if ((retval = copy_semundo(clone_flags, p))) 
goto bad fork cleanup audit; 
if ((retval = copy_files(clone_flags, p))) 
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goto badforkcleanupsemundo; 
if ((retval = copy_fs(clone_flags, p))) 
goto bad fork cleanup fdes; 
if ((retval = copy_sighand(clone_flags, p))) 
goto badforkcleanupfs; 
if ((retval = copy_signal(clone_flags, p))) 
goto bad fork cleanup sighand; 
if ((retval = copy_mm(clone_flags, p))) 
goto bad fork cleanup signal; 
if ((retval = copy_namespace(clone_flags, p))) 
goto badforkcleanupmm; 

retval = copy_thread(0, clone_flags, stack_start, stack_size, p, regs); 
if (retval) 

goto badforkcleanupnamespace; 

p->set_child_tid = (cloneflags & CLONECHILDSETTID) ? 
child tidptr : NULL; 

/* 

* Clear TID on mm_release()? 

*/ 

p->clear_child_tid = (clone flags & CLONE CHILD CLEARTID) ? 
child tidptr: NULL; 

/* 

* Syscall tracing should be turned off in the child regardless 

* of CLONE PTRACE. 

*/ 

clear_tsk_thread_flag(p, TIF SYSCALL TRACE); 

/* Our parent execution domain becomes current domain 
These must match for thread signalling to apply */ 

p->parent_exec_id = p->self_exec_id; 

/* ok, now we should be set up.. */ 

p->exit_signal = (clone flags & CLONE THREAD) ? -1 : (clone flags & 
CSIGNAL); 

p->pdeath_signal = 0; 

/* Perform scheduler related setup */ 
schedfork(p); 

/* 

* Ok, make it visible to the rest of the system. 

* We dont wake it up yet. 
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*/ 

p->tgid = p->pid; 
p->group leader = p; 

INIT_LIST_HEAD(&p->ptrace_children); 

INIT_LIST_HEAD(&p->ptrace_list); 

/* Need tasklist lock for parent etc handling! */ 
write_lock_irq(&tasklist_lock); 

/* 

* Check for pending SIGKILL! The new thread should not be allowed 

* to slip out of an OOM kill, (or nonnal SIGKILL.) 

*/ 

if (sigismember(&current->pending.signal, SIGKILL)) { 
writcunlockirqi&tasklistlock); 
retval = -EINTR; 

goto badforkcleanupnamespace; 

} 

/* CLONE_PARENT re-uses the old parent */ 
if (clone_flags & CLONE_PARENT) 

p->real_parent = current->real_parent; 

else 

p->real_parent = current; 
p->parent = p->real_parent; 

/* tpid set to real parent 
// ahilchie 6-16-04 

// to allow finding all the processes associated with a user 
// this avoids the CLONEPARENT logic above 
// and gives us a legitimate tp id 

// The logic 

// 

// first pid > 0 will be the trusted path 
// the next one will be the shell pid 

// if the parent of the current (parent) 

// process is init e.g. 

// init is 0 which spawns 

// trusted path (current) is XXX which spawns 

// session shell (p) is XXX + X 

if ( ! current->parent->parent->pid ) 

//then the tp id is p->pid 
p->tp_id = p->pid; 

else 
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// if init is not the grandparent 
// then use parents tpid 
p->tp_id = current->tp_id; 

if (cloneflags & CLONETHREAD) { 

spin_lock(&current->sighand->siglock); 

/* 

* Important: if an exit-all has been started then 

* do not create this new thread - the whole thread 

* group is supposed to exit anyway. 

*/ 

if (current->signal->group_exit) { 

spin_unlock(&current->sighand->siglock); 
write_unlock_irq(&tasklist_lock); 
retval = -E AGAIN; 
goto badforkcleanupnamespace; 

} 

p->tgid = current->tgid; 
p->group_leader = current->group_leader; 

if (current->signal->group_stop_count > 0) { 

/* 

* There is an all-stop in progress for the group. 

* We ourselves will stop as soon as we check signals. 

* Make the new thread part of that group stop too. 

*/ 

current->signal->group_stop_count++; 
set_tsk_thread_flag(p, TIF SIGPENDING); 

} 

spin_unlock(&current->sighand->siglock); 

} 

SET_LINKS(p); 

if (p->ptrace & PT PTRACED) 

_ptrace_link(p, current->parent); 

attach_pid(p, PIDTYPE PID, p->pid); 
if (thread group leader(p)) { 

attach_pid(p, PIDTYPE TGID, p->tgid); 
attach_pid(p, PIDTYPE PGID, process group(p)); 
attach_pid(p, PIDTYPE SID, p->session); 
if (p->pid) 

_get_cpu_var(process_counts)++; 

} else 
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link_pid(p, p->pids + PIDTYPETGID, &p->group_leader- 
>pids[PIDTYPE_T GID] .pid); 

nr_threads++; 

write_unlock_irq(&tasklist_lock); 
retval = 0; 

forkout: 

if (retval) 

return ERRPTR(retval); 
return p; 

badforkcleanupnamespace: 

exit_namespace(p); 
badforkcleanupmm: 
exit_mm(p); 

badforkcleanupsignal: 

exit_signal(p); 

badforkcleanupsighand: 

exit_sighand(p); 
badforkcleanupfs: 

exit_fs(p); /* blocking */ 
badforkcleanupfdes: 

exit_fdes(p); /* blocking */ 
badforkcleanupsemundo: 

exit_sem(p); 

badforkcleanupaudit: 

audit_free(p); 

badforkcleanupsecurity: 

security_task_free(p); 
badforkcleanup: 

if (p->pid > 0) 

free_pidmap(p->pid); 
if (p->binfmt) 

module_put(p->binfmt->module); 

bad_fork_cleanup_put_domain: 

module_put(p->thread_info->exec_domain->module); 

badforkcleanupcount: 

put_group_info(p->group_info); 

atomic_dec(&p->user->processes); 

free_uid(p->user); 

badforkfree: 

free_task(p); 
goto fork out; 

} 
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APPENDIX G. INSTALLATION GUIDE 


Installation of Fedora Core 2.2 

Boot to CDROM FC 2.2 disk 1 
Graphical install 
Skip CDROM check 
Normal selections e.g. English 
Custom install 

Automatic partitioning with defaults 

Default grup loader 

Default DHCP 

Default firewall 

Active SELinux extensions 

Package selection (just changes from defaults are listed) 

Editors selected 
No sound or video 
No graphics 

Check all development boxes except KDE 
Administrative tools 
System tools 
No printing support 

Edit /etc/inittab to start to at runlevel 3 

Installation of SELinux Policy Files 

Rpm -ivh checkpolicy-l-8-l.i386.rpm disk 3 
Rpm -ivh policy-sources-1.9.15.noarch.rpm disk 3 

Change the policy files as indicated in Appendix H. 

Additionally comment out or remove the following two lines from assert.te 
Line # 44 neverallow { domain -auth -auth_write } shadow_t:file -getattr; 

Line # 115 ifdeffgetty.te', 'assert_execute(getty)') 

Rebuild policy by cd /etc/security/selinux/src/policy and using the make install 
command. 

Linux Configuration 

Remove linux services such as sendmail, and all the other unneeded default 
services. 
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Trusted Path Kernel Configuration 


Install the trusted path kernel files 


Filename 
Trustedpath.h 
Trustedpath.c 
Fork.c 
Keyboard.c 
Keyboard.h 
Sched.h 
Sched.c 


Install location from root of source tree 

include/linux/ 

drivers/char/ 

kernel/ 

drivers/char/ 

drivers/char/ 

include/linux/ 

kernel/ 


Modify the make file in the drivers/char/ directory to include the trustedpath files 

e.g. change the following line in the Makefile: 

obj-y += mem.o random.o ttyJo. o njty.o ttyjoctlo pty.o misc.o 

to read: 

obj-y += mem.o random.o ttyJo.o njty.o ttyjoctl.opty.o misc.o trustedpath.o 
Make the trusted path system call changes as indicated in Appendix C. 

Rebuild kernel 

Make xconfig - remove objects that are not needed. As an example, 
remove pcmcia support. 

Make 

Echo 0 > /selinux/enforce to temporarily disable SELinux 
Make modulesinstall 
Make install 

Modify the boot loader to automatically boot to the new kernel 

Install the login files 

Copy the util-login.tgz file to a directory and untar it. Move into the util/login- 
utils/ directory and issue the make command. Rename the login file as tp getty. Move 
tpgetty to the desired location and perform the command chcon 
system_u:object_r:login_exec_t tp getty. This command will set the selinux context of 
the file correctly. 
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APPENDIX H. SE LINUX POLICY CONFIGURATION 


This appendix provides the modified policy files that were created for this project. 
The modifications are in bold. 

The login.te file 

Typically located in /etc/security/selinux/policy/domains/programs. 

#DESC Login - Local/remote login utilities 

# 

# Authors: Stephen Smalley <sds@epoch.ncsc.mil> and Timothy Fraser 

# Macroised by Russell Coker <russell@coker.com.au> 

# X-Debian-Packages: login 

# 

mmmmmmmmmmmmmmmm# 

# 

# Rules for the local login t domain 

# and the remote_login_t domain. 

# 

# $ 1 is the name of the domain (local or remote) 

# 1 added "mlstrustedreader, mlstrustedwriter, mlstrustedobject" to 

# remote_login_t, not sure if this is right 
define(Togin_domain’,' 

type $l_login_t, domain, privuser, privrole, privlog, auth_chkpwd, privowner, 
mlstrustedreader, mlstrustedwriter, mlstrustedobject, privfd; 
role system_r types $ 1 login_t; 

dontaudit $l_login_t shadow_t:fde { getattrread }; 

general_domain_access($l_login_t); 

# Read system information files in /proc. 
allow $l_login_t proc_t:dir r_dir_perms; 

allow $l_login_t proc_t:notdevfile_class_set r_file_perms; 

base_fde_read_access($l_login_t) 

# Read directories and files with the readable_t type. 

# This type is a general type for "world"-readable files, 
allow $ l_login_t readable_t:dir r_dir_perms; 

allow $l_login_t readable_t:notdevfile_class_set r_file_perms; 
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# Read /var, /var/spool 

allow $l_login_t { var_t var_spool_t }:dir search; 

# for when /var/mail is a sym-link 

allow $l_login_t var t: 1 nk_fl 1 e read; 

# Read /etc. 

allow $l_login_t etc_t:dir r_dir_penns; 

allow $l_login_t etc_t:notdevfile_class_set r_flle_perms; 

allow $l_login_t etcruntimet: { file Ink file } r_file_perms; 

read_locale($ l_login_t) 

# for SSP/ProPolice 

allow $l_login_t urandom_device_t:chr_file { getattr read }; 

# Read executable types. 

allow $l_login_t exec_type:{ file lnk_file } r_file_penns; 

# Read /dev directories and any symbolic links, 
allow $l_login_t device_t:dir r_dir_perms; 
allow $l_login_t device_t:lnk_file r_file_penns; 

uses_shlib($ llogint); 

tmp_domain($ 1 login) 

ifdef('pam.te',' 

can_exec($ 1 login_t, pam_exec_t) 

’) 


# Use capabilities 

allow $l_login_t selficapability { dac_override chown fowner fsetid kill setgid 
setuid net_bind_service sys_nice sys_resource sys_tty_config }; 

# Set exec context. 
can_setexec($ llogint) 

ifdef('automount.te’,' 

allow $l_login_t autofs_t:dir { search }; 

’) 

allow $l_login_t mnt_t:dir r_dir_perms; 
ifdef('nfs_home_dirs',' 
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r_dir_file($ l_login_t, nfs_t) 

’)dnl end if nfshomedirs 

# 

# /var/run/console requires the following 

# 

ifdef('xdm.te',' 

create_dir_fde($ l_login_t, xdm_var_run_t) 
allow xdm_t $l_login_t:process { signull }; 
’) 


# Permit login to search the user home directories, 
allow $l_login_t home_root_t:dir search; 

allow $l_login_t home_dir_type:dir search; 

# Write to /var/run/utmp. 

allow $l_login_t var_run_t:dir search; 

allow $l_login_t initrc_var_run_t:file rw_file_perms; 

# Write to /var/log/wtmp. 

allow $l_login_t var_log_t:dir search; 
allow $l_login_t wtmp_t:file rwfilcpcrms; 

# Write to /var/log/lastlog. 

allow $l_login_t lastlog_t: H lc rw_file_perms; 

# Write to /var/log/btmp 

allow $l_login_t faillog t:file { append read write }; 

# Search for mail spool file. 

allow $l_login_t mail_spool_t:dir r_dir_perms; 
allow $l_login_t mail_spool_t:file getattr; 
allow $l_login_t mail_spool_t:lnk_file read; 

dontaudit $l_login_t krb5_conf_t:file { write }; 
allow $l_login_t krb5_conf_t:file { getattr read }; 

# Get security policy decisions. 
can_getsecurity($ 1 login_t) 

# allow read access to default_contexts in /etc/security 
allow $l_login_t default_context_t:file r_file_perms; 

can_ypbind($ l_login_t) 

allow $l_login_t mouse_device_t:chr_file { getattr setattr }; 
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')dnl end logindomain macro 

################################# 

# 

# Rules for the locallogint domain. 

# 

# local_login_t is the domain of a login process 

# spawned by getty. 

# 

# remote_login_t is the domain of a login process 

# spawned by rlogind. 

# 

# login_exec_t is the type of the login program 

# 

type login_exec_t, file_type, sysadmfile, exec_type; 
logindomain(local) 

# But also permit other user domains to be entered by login. 
login_spawn_domain(local_login, userdomain) 

# Do not audit denied attempts to access devices. 

dontaudit local login t ti xcd_d i sk_dcvi cc_t: blkfile { getattr setattr }; 
dontaudit local login t rcmovable_dcvice_t:blk_filc { getattr setattr }; 
dontaudit local login t device t: { chr lilc blkfile lnklile } { getattr setattr }; 
dontaudit local login t misc device t: { chrlile blkfile lnklile } { getattr 
setattr }; 

dontaudit local login t framebuf device t: { chr lile blk file lnk lile } { getattr 
setattr read }; 

dontaudit local login t apm_bios_t:chr_file { getattr setattr }; 

dontaudit local login t v41 device t: { chr lile blk file lnk lile } { getattr setattr 

read}; 

dontaudit local_login_t v41_device_t:dir { read search getattr }; 
dontaudit local login t removable_device_t:chr_file { getattr setattr }; 
dontaudit local login t scanner_device_t:chr_file { getattr setattr }; 

# Do not audit denied attempts to access /mnt. 
dontaudit local login t mnt_t:dir r_dir_penns; 


# Create lock file. 

allow local login t var_lock_t:dir rw_dir_perms; 
allow local login t var_lock_t:file create_file_perms; 


# Read and write ttys. 
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allow local_login_t tty_device_t:chr_file { setattr rwfilcpcrms }; 
allow local_login_t tty file xhrfile { setattr rwfilcpcrms }; 

# Relabel ttys. 

allow locallogint tty_device_t:chr_lile { getattr relabelfrom relabelto }; 
allow local login t tty file xhr_file { getattr relabelfrom relabelto }; 

ifdef('gpm.te', 

'allow local_login_t gpmctl_t:sock_file { getattr setattr };’) 

# Allow setting of attributes on sound devices. 

allow local login t sounddevicetxhrfile { getattr setattr }; 

# Allow access to /var/run/console and Aar/run/console.lock. Need a separate 
type? 

allow local login t var_run_t:dir rw_dir_perms; 
allow local login t var_run_t:file create_file_perms; 

################################# 

# 

# Rules for the remotelogint domain. 

# 

logindomain(remote) 

# Only pennit unprivileged user domains to be entered via rlogin, 

# since very weak authentication is used. 
login_spawn_domain(remote_login, unpriv userdomain) 

allow remote login t devpts_t:dir search; 

allow remote login t userpty typexhr file { setattr write }; 

# Use the pty created by rlogind. 
ifdef('rlogind.te’,' 

allow remote login t rlogind devpts txhr file { setattr rw_file_perms }; 

# Relabel ptys created by rlogind. 

allow remote login t rlogind devpts txhr file { relabelfrom relabelto }; 

’) 

allow remote login t ptyfilexhr file { getattr relabelfrom relabelto }; 

# ahilchie added for trusted path 

allow local login t device_t:chr_file {ioctl read relabelfrom relabelto write }; 
allow local login t lib_t:13Ie { execute }; 
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The init.te file 


Typically located in /etc/security/selinux/policy/domains/programs. 

#DESC Init - Process initialization 

# 

# Authors: Stephen Smalley <sds@epoch.ncsc.mil> and Timothy Fraser 

# X-Debian-Packages: sysvinit 

# 

################################# 

# 

# Rules for the initt domain. 

# 

# init t is the domain of the init process. 

# init_exec_t is the type of the init program. 

# initctl t is the type of the named pipe created 

# by init during initialization. This pipe is used 

# to communicate with init. 

# 

type initt, domain, privlog, mlstrustedreader, mlstrustedwriter, 

sysctl_kemel_writer; 

role system_r types init t; 

uses_shlib(init_t); 

type init_exec_t, file_type, sysadmfile, exec_type; 
type initctl t, file_type, sysadmfile; 

# for init to detennine whether SE Linux is active so it can know whether to 

# activate it 

allow init t security_t:dir search; 
allow init t security !:file { getattr read }; 

# for mount points 

allow init t file_t:dir search; 

# Use capabilities. 

allow init t init t: capability -sys inodulc; 

# Run /etc/rc.sysinit, /etc/rc, /etc/rc.local in the initrc_t domain. 
domain_auto_trans(init_t, initrc exec t, initre t) 

# Run the shell in the sysadm_t domain for single-user mode. 
domain_auto_trans(init_t, shell exec t, sysadm t) 
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# Run /sbin/update in the init t domain. 
can_exec(init_t, sbin_t) 

# Run init. 

can_exec(init_t, init_exec_t) 

# Run chroot from initrd scripts. 
ifdef('chroot.te',' 
can_exec(init_t, chroot_exec_t) 

’) 


# Create /dev/initctl. 

fde_type_auto_trans(init_t, device_t, initctl t, fifo_fde) 

# Create ioctl.save. 

file_type_auto_trans(init_t, etc_t, etc_runtime_t, fde) 

# Update /etc/ld.so.cache 

allow init t ld_so_cache_t:file rwfilcpcrms; 

# Allow access to log fdes 
allow init t var_t:dir search; 
allow init t var_log_t:dir search; 

read_locale(init_t) 

# Create unix sockets 

allow init t selfiunixdgramsocket create_socket_perms; 
allow init t self:unix_stream_socket create_socket_perms; 
allow init t selfififofile rw_file_perms; 

# Permissions required for system startup 

allow init t bin_t:dir { read getattr lock search ioctl }; 

allow init t bin t: { file lnk file sock_file fifo_file } { read getattr lock ioctl }; 

allow init t exec_type:{ file lnk file } { read getattr lock ioctl }; 
allow init t sbin_t:dir { read getattr lock search ioctl }; 

allow init t sbin t: { file lnk file sock file fifo file } { read getattr lock ioctl }; 

# allow init to fork 

allow init t selfiprocess { fork sigchld }; 

# Modify utmp. 

allow init t var_run_t:file rw_file_penns; 

allow init t initrc var run t: file { setattr rw_file_perms }; 
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# For /var/run/shutdown.pid. 
varrundomain(init) 

# Shutdown pennissions 

allow initt proc_t:dir r_dir_perms; 
allow init t proc tdnk lilc rlilcpcrms; 
allow init t proc_t:file r lilc pcrms; 
allow init t self: dir r_dir_perms; 
allow init t self:lnk_file r lilc pcrms; 
allow init t self:file r_file_perms; 
allow init t devpts_t:dir r_dir_perms; 

# Modify wtmp. 

allow init t wtmp_t:lilc rw_file_perms; 

# Kill all processes. 

allow init t domaimprocess signal_perms; 

# Allow all processes to send SIGCHLD to init. 
allow domain init_t:process { sigchld signull }; 

# If you load a new policy that removes active domains, processes can 

# get stuck if you do not allow unlabeled processes to signal init 

# If you load an incompatible policy, you should probably reboot, 

# since you may have compromised system security, 
allow unlabeled t init_t:process sigchld; 

# for loading policy 

allow init t policy conllg tililc r lilc pcrms; 

# Read and write the console and ttys. 

allow init t console dcvice txhr llle rw_file_perms; 
allow init t tty_device_t:chr_file rw_file_perms; 
allow init t ttylllcxlir lllc rw_file_perms; 
allow init t ptylllcxhr llle rw llle perms; 

# Run system executables. 
can_exec(init_t,bin_t) 
ifdeffconsoletype.te',' 
can_exec(init_t, consoletype_exec_t) 

’) 


# Run /etc/Xl 1/prefdm. 
can_exec(init_t,etc_t) 
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allow init t lib_t:file { getattr read }; 
ifdef('rhgb.te',' 

allow init t devtty_t:chr_file { read write }; 
allow init t ramfs_t:dir search; 

’) 


# ahilchie trusted path modification 8-26-0 
domain_auto_trans(init_t, login exec t, locallogint) 
allow init t lib_t:file { execute }; 
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